SocialRobot MCP Server

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

Annotations already show this is a non-read-only, non-destructive write operation. The description adds useful behavioral context beyond annotations: DIRECT_POST publishes to the TikTok profile while UPLOAD creates an inbox draft, and segment arrays chain replies from a root post. No contradiction with annotations.

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

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

Three focused sentences: the first states the core purpose, and the following sentences add high-value platform-specific parameter guidance. There is no fluff or repetition of schema content.

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

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

For a 10-parameter, multi-network creation tool with no output schema and zero schema description coverage, this description is incomplete. It omits scheduling modes (DRAFT/NOW/SCHEDULE), account connection prerequisites, return values, error behavior, and guidance for most target platforms.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries a heavy burden for explaining parameters. It does add genuine semantics for postMode, privacyLevel, and the segments arrays. However, it leaves the other platform target arrays (Instagram, Pinterest, LinkedIn, Facebook, Mastodon, Bluesky) without any explanatory guidance.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific action (create) and resource (one scheduled item that publishes to social accounts), and clearly separates it from sibling tools like update_post, delete_post, and list_posts. The multi-account and scheduling scope adds specificity beyond the title.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit platform-specific usage instructions: TikTok requires choosing between DIRECT_POST and UPLOAD, with privacyLevel sourced from tiktok_get_creator_info, and X/Threads use ordered segments for threaded replies. It does not explicitly contrast with sibling creation-related tools, but the create-vs-update/delete distinction is self-evident.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, matching the description's 'Delete' semantics. The description adds value beyond the annotations by disclosing two behavioral constraints: only draft/scheduled posts can be deleted, and ownership by the authenticated user is required. It could mention irreversibility, but destructiveHint already covers the risk profile.

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

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

A single sentence with zero filler. The key distinction (draft or scheduled) is front-loaded immediately after the verb, making the definition scannable and efficient.

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

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

For a simple single-parameter delete operation with annotations covering the destructive safety profile, the description covers the essential context: what can be deleted and by whom. The main gap is the undocumented 'id' parameter and the unspecified success response, but no output schema exists and the tool's simplicity limits the impact.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate by explaining the 'id' parameter, but it never does. An agent cannot tell from the description that 'id' refers to the post identifier. The description mentions the post type but provides no mapping to the actual parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names a specific verb ('Delete') and resource ('a draft or scheduled post'), and adds a scope qualifier ('belongs to the authenticated user'). This clearly distinguishes it from siblings like create_post, update_post, and schedule_post by stating what kind of posts are eligible for deletion.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The qualifiers 'draft or scheduled' and 'belongs to the authenticated user' establish clear usage boundaries: this tool is for removing unpublished, user-owned posts. It does not explicitly name alternatives or state exclusions, but the context is unambiguous enough that an agent can infer when to select it.

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

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

Annotations already mark this as read-only and non-destructive, so the description need not re-prove safety. It adds useful context about the account-level scope and the requirement that the account be connected, but it does not disclose details such as auth requirements, rate limits, or response shape.

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

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

The description is a single, well-structured sentence with no filler. It delivers the core action and scope immediately.

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

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

With no output schema and no parameter descriptions, the description leaves important context unspecified, such as what analytics metrics are included, what the response series looks like, and how this differs from post-level or demographic analytics. It is minimally sufficient but not complete for an agent making an informed tool selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It only vaguely references 'a date range', leaving platform, accountId, and date format details to inference. The schema itself provides patterns and enums, but the description adds almost no semantic guidance beyond that.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a clear verb ('Return'), a specific resource ('account-level analytics series'), and a scope ('connected social account over a date range'). The term 'account-level' distinguishes it from sibling tools like get_post_analytics and get_follower_demographics.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context: use this tool when you need account-level analytics for a social account over a date range. It does not explicitly name sibling alternatives or state exclusion cases, so it stops short of a 5.

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

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

The readOnly and destructive annotations already cover safety, and the description adds meaningful behavioral context: Instagram/Facebook/Threads return follower breakdowns while LinkedIn returns lifetime demographics with different fields. This goes beyond annotations without contradicting them.

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

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

Two concise sentences, front-loaded with the primary purpose, and the second sentence adds valuable platform distinctions without repetition. Every sentence earns its place.

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

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

The description gives platform-specific return expectations, but lacks full context for correct invocation: no explanation of the 'breakdown' enum meaning, the 'locale' parameter, or whether LinkedIn's seniority/industry are returned regardless of breakdown. With no output schema, more detail would be warranted.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning, but it does not explain 'breakdown', 'locale', or 'accountId' explicitly. It only hints at 'platform' by naming platforms. This leaves key parameters under-specified.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb ('Return') and resource ('audience demographics for a connected social account'), immediately distinguishing it from post-level analytics siblings. It further clarifies platform-specific outputs, making the tool's scope unambiguous.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when follower demographics are needed—and provides platform-specific expectations. However, it does not explicitly state when not to use it or mention alternatives like get_account_analytics.

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

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

The description goes beyond the annotations by explaining the presigned URL workflow, the requirement to PUT file bytes, and the follow-up call to create_post. Annotations only indicate non-read-only behavior, so this added context is valuable. It does not mention URL expiration or auth details, but the core behavior is transparent.

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

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

The description is compact, front-loaded with the most important guidance, and every sentence contributes actionable information. There is no filler or redundancy.

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

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

For a presigned-upload flow with no output schema, the description covers the key steps: get URL, PUT bytes, pass public URL into create_post, and fallback to upload_media. Minor ambiguity around 'returned public url' and missing upload constraints prevent a perfect score, but the essential workflow is complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description does not explain filename or contentType. The parameter names are somewhat self-explanatory, but the description adds no meaning about expected formats, required conventions, or how they relate to the presigned URL generation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly identifies the operation as obtaining a presigned media upload URL and distinguishes it from the sibling upload_media tool. The verb-resource pairing is explicit and unambiguous.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly states when to use this tool (when HTTP PUT is available) and when to use the alternative (upload_media when the storage host is unreachable). This gives the agent actionable routing guidance.

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

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

Annotations already mark the tool as read-only and non-destructive, so the description does not need to repeat that. It adds meaningful behavioral context by disclosing the 50-pin upper bound, the ranking-by-metric behavior, and the enrichment with SocialRobot publish data 'when available.' This goes beyond what annotations provide.

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

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

The description is two sentences with no filler. It leads with the core action and resource, then the key constraints and data-enrichment detail. Every phrase earns its place.

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

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

The description is sufficient for a read-only analytics tool with a simple schema: it states what is returned, the limit, the ranking dimension, and the enrichment behavior. It does not describe response shape, but given the lack of an output schema, the description still provides enough context for correct invocation and expectation setting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden of explaining parameters. It maps accountId to 'Pinterest account', startDate/endDate to 'for the date range', and sortBy to 'ranked by impressions or another metric.' This adds useful conceptual meaning even though it does not enumerate exact defaults or enum behavior, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb and resource: 'Return Pinterest account top pins' with a clear bound ('up to 50') and ranking criterion ('by impressions or another metric'). It clearly identifies the Pinterest-specific nature and differentiates itself from sibling tools like get_account_analytics or get_posts_with_analytics.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving top Pinterest pins within a date range, but it does not explicitly state when to prefer this tool over sibling analytics tools or when not to use it. No alternatives or exclusions are mentioned, so the guidance is present but implicit.

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

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

Annotations already communicate read-only and non-destructive behavior; the description adds meaningful context by saying the data is 'raw' and that the metric set is 'platform-specific'. It does not cover auth expectations, rate limits, or return structure, but this is a simple read-only tool.

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

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

One front-loaded sentence with no wasted words: 'Return raw analytics' states the action immediately, and each clause adds relevant scope or behavior.

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

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

For a two-parameter read-only tool with annotations, the description is mostly complete: it identifies the resource, granularity, lifecycle state, and platform-dependence of results. The main missing piece is explicit differentiation from sibling analytics tools and a little more parameter-level detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema has 0% property descriptions, so the description must compensate. It gives targetId useful meaning ('single published platform target') and clarifies that platform changes the metric set returned. Still, it does not explain how to obtain/format targetId or what the metric sets contain.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a clear verb ('Return') and a specific resource ('raw analytics for a single published platform target'). It implies distinction from account-level and multiple-post siblings via 'single' and 'platform target', but it does not explicitly name or compare alternatives.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'published' and 'single' provides useful context: this tool is for one already-published platform target, not for drafts, account analytics, or bulk listing. However, it stops short of explicitly stating when-not-to-use or pointing to sibling tools such as get_accountanalytics or get_posts_with_analytics.

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

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

The annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the useful constraints that only published posts are returned and an account must be connected, but it does not disclose pagination, defaults, or date-range behavior.

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

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

The description is a single, front-loaded sentence with no filler. It states the verb, resource, and differentiators efficiently.

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

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

With five parameters, no output schema, and no parameter descriptions, the tool needs more context than this one-sentence summary provides. Missing details include response structure, date filtering semantics, limit defaults, and how 'historical points' relate to startDate/endDate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description needed to compensate for the five parameters. It does not explain limit, startDate, endDate, accountId, or platform semantics; 'connected account' only loosely maps to accountId, and the parameter names and schema constraints carry most of the meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the operation: listing published posts, and it adds a distinguishing feature: the posts come with analytics snapshots and historical points. It does not explicitly name sibling tools like list_posts or get_post_analytics, so differentiation is implicit rather than direct.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus list_posts or get_post_analytics. The only context is 'for a connected account,' which acts as a prerequisite rather than a usage decision or exclusion.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the read-only nature is covered. The description adds useful behavioral context by specifying that guidance is personalized and derived from past post performance, which tells the agent the computation basis and reinforces that this tool does not modify content.

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

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

The description is a single front-loaded sentence with no filler. Every phrase earns its place: the verb, the result, the account scope, and the data source. It is optimally concise for an agent to parse quickly.

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

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

For a one-parameter read-only tool with no output schema, this description plus annotations cover the essential information: what it returns, for whom, and from what data. The main omission is expected response format, but with no output schema and a simple 'guidance' return, this is not a critical gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate, but 'for a connected Instagram account' is the only indirect clue that accountId refers to the connected Instagram account ID. The param name is self-explanatory and the tool context helps, yet the description never explicitly maps accountId to a real-world value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb ('Return') with a concrete resource ('personalized best-posting-time guidance') and a clear scope ('connected Instagram account'). The phrase 'based on past post performance' explains the underlying method, and this clearly distinguishes the tool from siblings like get_post_analytics or get_account_analytics.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the use case: when an agent needs best-posting-time guidance for an Instagram account. However, it does not explicitly state when not to use it or compare it with sibling tools such as get_account_analytics or get_follower_demographics, so the routing guidance is left to inference.

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

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

Annotations already mark the tool as read-only and non-destructive, and the description adds useful behavioral context beyond that: the search is backed by Bing, results are meant to be passed into create_post, and the tool requires a Company Page account with a follower threshold. This is substantive context and does not contradict the annotations.

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

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

The description is compact and front-loaded: it states the core function first, then the downstream usage, then the prerequisites. Every sentence adds necessary information and there is no filler.

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

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

The description explains purpose, downstream use, and prerequisites, and the 'urn + displayText' hint partially compensates for the missing output schema. However, with no output schema and no parameter-level documentation, the agent is left to infer the exact meaning of query and accountId and the full shape of the response. It is adequate for selection but not fully complete for invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must explain the two required parameters, but it only weakly implies that query is the search term. accountId is never explicitly tied to the Company Page account or explained as an identifier. The description mentions the output fields urn and displayText, but does not clarify how they relate to the input parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description names the specific operation: 'Search Bing geo locations' for LinkedIn Company Page organic targeting. It also differentiates the tool from sibling search tools like linkedin_search_organizations and linkedin_search_people_mentions by pointing to a distinct resource type, geo locations, and by explaining how results flow into create_post.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete usage context: use this tool to obtain geo-location targets for LinkedIn Company Page posts via create_post. It also states prerequisites including the need for a Company Page account and more than 300 matching Page followers. It does not explicitly name alternatives or say when not to use it, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: query is a vanity lookup, omitting it falls back to Your Pages, and a connected Page CM token is required for auth. This goes beyond the annotations without contradicting them.

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

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

Three dense sentences, each earning its place: the lookup behavior, the compose/auth context, and the downstream integration hint. The sentence about passing type, urn, and displayText is slightly jargon-heavy but useful. It is front-loaded with the core purpose and does not waste space.

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

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

Given there is no output schema, the description compensates by revealing the relevant output fields (type, urn, displayText) and how to use them in create_post mentions. It also covers auth and query fallback. The main gap is the unexplained required accountId parameter and the undefined 'CM token' acronym, but the overall picture is actionable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides no description for either parameter, so the description must carry the semantic load. It explains query behavior well (vanity lookup, fallback when omitted) and indirectly hints at account requirements via 'any connected Page CM token,' but it never explains the required accountId parameter. This is a partial but meaningful compensation for the schema gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

States a specific verb ('Resolve'), resource ('LinkedIn companies/organizations'), and use case ('for @mentions'), which immediately distinguishes it from sibling lookup tools like linkedin_search_people_mentions and linkedin_search_geo_locations. The mention of 'vanity Organization Lookup' and the Query-omitted fallback to 'Your Pages' adds precise scope without ambiguity.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear context for when to use the tool: for composing posts with company mentions, on both personal and Company Page compose, and requiring any connected Page CM token. It does not explicitly name alternative tools or state when not to use it, but the company-mention purpose and compose-scope guidance are enough to route an agent correctly.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds useful context about Company Pages and the mention-construction workflow, but it does not disclose response shape, pagination behavior, or any other edge-case behavior. This is adequate given the annotations, but not rich.

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

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

The description is concise, with the core action front-loaded in the first sentence and the integration detail in the second. No wasted words, though the second sentence is dense and could be restructured for greater clarity. Overall it is appropriately sized.

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

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

With no output schema, the description should explain what the tool returns and how accountId and query drive the search. It only hints at output fields via type/urn/displayText and omits response shape, pagination, and accountId semantics. The create_post integration note helps but leaves significant gaps for a read-only search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only types and constraints for accountId and query, with no parameter descriptions. The description does not explain what accountId or query mean, and instead introduces type, urn, and displayText, which are not input parameters. This leaves the actual input semantics unclear and could confuse an agent.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a concrete action ('Search Page followers') and a clear scope ('LinkedIn @mentions, Company Pages only'), which helps distinguish it from sibling tools like linkedin_search_geo_locations and linkedin_search_organizations. However, the second sentence is phrased as integration instructions for create_post rather than a plain restatement of purpose, leaving slight ambiguity about what exactly the search returns.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit context: Company Pages only, and how to pass type, urn, and displayText into captionMentions or firstCommentMentions when creating a post. It provides clear guidance for using the tool in the create_post workflow, though it does not explicitly discuss when not to use it or compare it to sibling search tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context: it lists 'every' connected account, implying complete enumeration rather than a filtered subset, and frames access as tied to the authenticated user. This is consistent with annotations and adds value beyond safety flags.

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

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

One sentence, no filler, action-first wording. Every word contributes meaning: 'List', 'every', 'connected social account', and 'authenticated user' all add distinct information.

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

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

For a zero-parameter, read-only listing tool, the description covers the key facts: what is listed, for whom, and that it is the full connected set. It does not describe the response format, but the term 'List' strongly implies an array, and output schema is absent. Minor additional detail about authentication requirements or return structure would push it to full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters, so the schema carries no semantic load. The description's mention of the authenticated user appropriately clarifies how result scoping works, which is the only meaningful parameter-like context for this operation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

Uses a specific verb 'List' with a clear resource ('Connected social accounts') and clearly sets user scope ('available to the authenticated user'). This distinguishes it from sibling tools like list_posts or get_account_analytics without needing to open the schema.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides no explicit guidance on when to use this tool versus alternatives, and no 'when-not-to-use' or sibling comparisons. The user scope is stated, but the decision boundary between this and related account tools is left unaddressed.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds the authenticated-user scope and a partial list of statuses, but it does not disclose pagination behavior, default sort, or rate limits. It also silently omits FAILED and PARTIALLY_PUBLISHED enum values, which could mislead an agent into thinking those statuses are not listable.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to stating the operation and primary scope, making it easy to parse quickly.

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

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

With seven parameters, no output schema, and no parameter descriptions, this definition is too sparse for an agent to invoke correctly in all cases. It lacks guidance on filtering by date/platform, cursor pagination, sorting, and the full status list. The read-only annotations reduce safety concerns but do not fill these functional gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the seven parameters. It only touches the status concept by naming four of the six enum values, and provides no meaning for sort, limit, cursor, dateFrom, dateTo, or platform. This is a significant gap for parameters that have no descriptions in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific verb ('List') and resource ('posts') scoped to the authenticated user, making the core purpose clear. It is distinguishable from mutation siblings like create_post and delete_post, though it does not explicitly differentiate itself from get_posts_with_analytics. It also omits two statuses present in the schema (PARTIALLY_PUBLISHED, FAILED), slightly muddying the exact scope.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

No usage guidance is provided beyond the basic listing intent. There is no mention of when to choose this tool over get_posts_with_analytics, reschedule_post, or other siblings, and no exclusions or prerequisites are stated.

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

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

Annotations already indicate this is a mutating but non-destructive operation, and the description's mention of a 'connected' account adds a small amount of context about external side effects. However, it does not disclose details like creation limits, default privacy, or success/failure behaviors.

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

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

The description is a single, direct sentence with no wasted words. It is immediately understandable and front-loaded with the primary action.

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

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

Given four parameters, no output schema, and minimal parameter guidance, the description is too sparse to fully guide an agent. Missing details like privacy default, return value, and any preconditions for the connected account mean an agent must infer significant information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for parameter meaning. It weakly implicates accountId via 'connected Pinterest account' and name via 'new board', but it does not explain privacy or description parameters, and it does not clarify required input semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb ('Create') with a specific resource ('Pinterest board') and scopes it to a connected Pinterest account. This clearly distinguishes it from siblings like pinterest_list_boards and create_post.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when a new Pinterest board needs to be created, but it does not name alternatives or provide when-not-to-use guidance. There is no explicit routing between this and sibling tools.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate safety. It adds the useful context that the account must already be connected, but it does not disclose output shape, pagination behavior, or failure modes. This is reasonable for a simple read-only listing tool, but not rich behavioral disclosure.

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

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

A single sentence that front-loads the action and resource without any filler. Every word contributes meaning, and the description is appropriately sized for such a simple tool.

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

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

For a one-parameter, read-only listing tool, the description provides a complete enough picture: it identifies the resource returned and the precondition of a connected account. The lack of an output schema is partially mitigated because the description clearly says the return value is boards, though it does not detail board object structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the only parameter, accountId, is left entirely to the schema without a property description. The description refers to a 'connected Pinterest account', which loosely implies that accountId identifies the connected account, but it does not explicitly explain the parameter's meaning, format, or where to source it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description states a specific verb ('Return') and resource ('Pinterest boards available for a connected Pinterest account'), clearly identifying what the tool does. It is easily distinguished from siblings like pinterest_create_board (create vs list) and list_posts (boards vs posts).

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'available for a connected Pinterest account' implies the tool should be used after an account has been connected, and the sibling list_connected_accounts is a natural source for accountId. However, there is no explicit guidance about when to use this tool versus alternatives, nor any exclusion criteria.

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

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

Annotations include readOnlyHint=false and openWorldHint=true, and the description adds the key behavioral fact that this mutates an existing post's publication date to a future time. It doesn't resort to tautology or contradict the annotations, and provides enough context beyond the structured fields.

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

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

A single, effective sentence that delivers the core semantics upfront with no filler. Every word adds value, and there is no redundant restating of the tool name.

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

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

For a simple two-parameter mutation tool with no output schema, the description covers the essential behavior. The only meaningful gaps are the exact format for scheduledFor and whether rescheduling is limited to already-scheduled posts, but these are minor for typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description must compensate. It implicitly maps 'existing post' to id and 'new future publication date' to scheduledFor, but doesn't specify the required date format (e.g., ISO 8601) or validate constraints. The description adds some meaning beyond the bare schema, but not enough for full clarity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the action ('Move'), the resource ('existing post'), and the target state ('new future publication date'). This distinguishes it from create_post and delete_post, making the purpose unambiguous.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'existing post' clearly signals when to use this tool, and 'new future publication date' implies the target scheduling window. It doesn't explicitly name alternatives, but the context is sufficiently clear for an agent to decide between this and create/delete.

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

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

Annotations already cover safety with readOnlyHint=true and destructiveHint=false. The description adds some context by identifying this as a pre-create_post lookup, but it does not disclose return formatting, pagination, or acount-specific prerequisites beyond what annotations and the description already imply.

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

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

Two sentence, no filler, and the primary purpose is front-loaded. Every clause contributes either to what the tool returns or when it should be used.

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

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

For a simple one-parameter read-only tool the description is minimally adequate: it enumerates return values and gives workflow context. However, with no output schema, it does not describe the shape or types of those values, and accountId resolution is left implicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the description only refers to 'an acount' without explaining how to obtain accountId, its format, or its relationship to tiktokTargets. The parameter name is somewhat self-explanatory, but the description does not sufficiently compensate for the missing schema documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description uses a specific verb ('Return') with a clear resource ('TikTok creator info') and explicitly lists the returned data fields: nickname, avatar, privacy_level_options, interaction settings, max video duration, and posting limits. It also distinguishes itself from post-centric siblings by tying the tool to create_post.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The second sentence gives explicit workflow guidance: 'Use before create_post with tiktokTargets.' This tells an agent when in the posting flow the tool should be called, though it does not mention exclusions or alternative tools.

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

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

Annotations establish readOnly=false and destructive=false; the description adds genuinely new behavioral context: the post-state constraint (draft/scheduled), the requirement that mediaUrl values be existing R2 URLs rather than arbitrary URIs, and the non-obvious side effect that passing a segments array 'replaces the whole thread chain (root caption/medias stay segment 1)'. No contradiction with the annotations.

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

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

Three sentences with zero filler: the purpose is front-loaded first, followed by two high-value operational specifics that each earn their place. For a tool this complex, the description stays remarkably tight without losing substance.

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

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

Given 11 required parameters, nine platform-specific target structures, and no output schema, the description covers the hardest non-obvious behaviors but leaves real gaps: it doesn't explain the scheduledFor publish-mode distinction, doesn't clarify how it relates to reschedule_post, and says nothing about return values. Adequate for a knowledgeable agent, but an agent meeting this tool cold would still have open questions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With schema description coverage at 0%, the description must compensate, and it does on the two most critical parameters: the mediaUrl semantics (must be existing R2 URLs for unchanged assets) and the segments semantics (ordered array that replaces the whole thread). However, the scheduledFor modes (DRAFT/NOW/SC HEDULE) and the nine platform-target arrays receive no prose explanation, so compensation is partial despite covering the highest-risk points.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description opens with a specific verb ('Replace') and names the resource ('an existing draft or scheduled post') plus the replaceable fields (caption, media URLs, schedule, platform targets), making the core function clear and distinct from create_post/delete_post. However, it never explicitly differentiates itself from the sibling reschedule_post, which also touches scheduling on existing posts, so sibling differenti is incomplete.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides concrete operational guidance: 'Pass existing R2 media URLs for unchanged assets' tells the agent how to preserve media during an update, and the X/Threads instruction explains exactly how to structure a thread replacement. There is no explicit when-to-use vs when-not-to-use statement or named alternative tool, so the choice against reschedule_post is left to inference.

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

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

Annotations only indicate readOnlyHint=false, destructiveHint=false, and openWorldHint=true, so the description carries the burden of behavioral disclosure. It adds meaningful detail: SocialRobot fetches the bytes, stores them, and returns a permanent URL. The 50MB limit further clarifies expected constraints, which goes beyond what annotations provide.

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

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

The description is compact and front-loaded, with the fallback context appearing first. Each sentence earns its place: fallback condition, input options, behavior, alternative preference, and size constraint. There is slight redundancy between the first sentence and 'Prefer get_media_upload_url when you can PUT,' but overall it is efficient and scannable.

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

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

For a tool with no required parameters, no output schema, and sparse schema descriptions, the description provides the essential operational picture: when to use it, what inputs are acceptable, what happens during execution, and what the return value is for. It does not explicitly state whether file and sourceUrl are mutually exclusive or what happens if both are provided, but the intended workflow is clear enough for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaning for two of the four parameters: 'file' as a ChatGPT file and 'sourceUrl' as a public https URL. However, 'filename' and 'contentType' remain unexplained, and the description does not clarify the relationship or precedence between them. It partially compensates for the schema gap but leaves room for ambiguity.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

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

The description clearly states the tool's role as a fallback media upload mechanism, explicitly distinguishes it from get_media_upload_url, and names the concrete outcome: returning a permanent URL for create_post. It uses a specific verb ('upload') and identifies the resource ('media'), making the tool's purpose immediately obvious.

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

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit when-to-use and when-not-to-use guidance: use this tool when you cannot PUT to the presigned URL, and prefer get_media_upload_url when PUT is possible. It also specifies allowed input modes ('ChatGPT file' vs 'public https sourceUrl') and the 50MB limit, giving an agent enough context to select and invoke the tool correctly.

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