Tulina

apify_linkedin_posts

LinkedIn posts matching a search, or published by given people or companies — text, author, date, reactions and comment counts. No LinkedIn login needed. harvestapi/linkedin-post-search.

Benchmark what performs on a topic, watch what a competitor or a prospect posts, or find who talks about a subject.

Returns — the LIST of posts (or {error, run_id, status, items}).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "apify_linkedin_posts"
  }
}

Input Schema

Name	Required	Description
`_org`	No	Org (id) de CET APPEL. `oto_list_orgs()`.
`_group`	No	Équipe (id) de CET APPEL, sous son org parente.
`fields`	No	keep only these keys of each post.
`_run_id`	No	OBLIGATOIRE à chaque appel dès `run_start` ou `data_claim_next` : sans lui, l'écriture sur une ligne réservée est refusée. Hérité seulement si le serveur tient un run actif — n'y compte pas.
`queries`	No	searches, as typed in LinkedIn's search bar (`"revops agency"`).
`sort_by`	No	`relevance` or `date`.
`_project`	No	Projet (id) de CET APPEL — jeton PRIMAIRE. `oto_project(op='list')`.
`_instance`	No	Instance de connecteur PRÉCISE (un credential exact). `oto_instance(op='list')`.
`max_posts`	No	posts per query or author.
`author_urls`	No	profile or company URLs whose posts (and reposts) you want.
`posted_limit`	No	only posts newer than this.
`with_comments`	No
`with_reactions`	No
`max_total_charge_usd`	No	hard cost ceiling of the run, $5 by default, at most your organization's ceiling per run ($25 unless set otherwise).

Schema Changelog

Changes observed during successful MCP inspections.

No schema history has been recorded yet.

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations, the description must carry the behavioral burden; it does disclose that no LinkedIn login is required and gives the return shape including the error envelope `{error, run_id, status, items}`. It says nothing about run/cost semantics (the $5 default ceiling and run_id requirement live only in the schema), rate limits, or pagination behavior, which matters for a 14-parameter scraping tool.

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?

Front-loaded with the capability, then a short use-case sentence, then a return-value line — each block earns its place and there is no filler. The use-case sentence is slightly decorative but still informative, keeping it just below a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, no-output-schema, no-annotation tool the description covers purpose, modes, use cases, auth-free operation and the return envelope, which is most of what an agent needs before calling. The notable omission is any mention of the cost ceiling and run-tracking semantics that dominate the schema's non-obvious parameters.

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 coverage is 86%, so the schema already documents nearly every parameter including queries, author_urls, max_posts and posted_limit. The description only restates the search-vs-author distinction at a high level and adds no format guidance (e.g. search operator syntax or URL shape) beyond what the schema provides — the baseline 3 applies.

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?

States a concrete verb+resource combination ('LinkedIn posts matching a search, or published by given people or companies') and enumerates the returned fields (text, author, date, reactions, comment counts). It implicitly distinguishes itself from profile/company siblings by scoping to posts, but never names an alternative tool such as linkedin_unipile_post or apify_linkedin_profiles, so an agent must infer the boundary.

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?

Three use cases are offered ('benchmark what performs on a topic, watch what a competitor or prospect posts, or find who talks about a subject'), which gives context but no explicit when-not or tool-selection rule. The description also implies the two modes (queries vs author_urls) without stating that they are mutually exclusive or combinable, leaving routing against the many LinkedIn siblings to inference.

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

All Tulina tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?