SocialRobot MCP Server

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

Annotations indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds behavioral context: it explains TikTok's two publish modes (DIRECT_POST vs UPLOAD) and thread chaining for X/Threads, which is beyond the schema. It does not contradict annotations and provides useful operational details.

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 and front-loaded with the primary purpose, then dives into platform-specific details. It is well-structured with clear sentences, though it packs a lot of information into a short space. No wasted words, but could be slightly more organized for readability.

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 the extremely large and complex input schema (10 top-level parameters, each with deep nesting) and no output schema, the description is insufficient. It does not explain many platform-specific fields (e.g., Facebook, LinkedIn, Pinterest, Instagram variants), return values, error handling, or scheduling behavior. The description covers only a fraction of what an agent needs to correctly invoke this 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?

Schema coverage is 0%, so the description must compensate. It explains postMode, privacyLevel (indirectly), and segments, but many other parameters (e.g., scheduledFor variants, media transforms, commercial content) are not described. The description adds some value but leaves many parameters unexplained given the tool's complexity.

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 creates a scheduled item that can publish to multiple social accounts, with specific platform details (TikTok modes, X/Threads threads). It distinguishes itself from sibling tools like update_post and delete_post by focusing on creation and scheduling. The verb 'create' and resource 'scheduled item' are specific 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?

The description provides concrete usage guidance for TikTok (postMode and privacyLevel), X and Threads (segments for threads). It implies when to use this tool (to create a post) but does not explicitly state when not to use it or mention alternatives like update_post. The guidance is clear for the key scenarios but lacks explicit exclusions.

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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the result is a series over a date range, but it does not disclose rate limits, pagination, timezone handling, or what metrics appear in the series. This is adequate but not richly 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?

A single sentence with no filler, front-loading the action and resource. Every word contributes to the tool's meaning.

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 core purpose and parameter mapping are covered, and annotations handle safety, but with no output schema the phrase 'analytics series' leaves the actual returned metrics undefined. It also omits explicit sibling routing, making the description adequate but not comprehensive.

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 schema has no parameter descriptions (0% coverage), so the description must compensate. It provides the key mapping: 'connected social account' corresponds to accountId/platform and 'date range' corresponds to startDate/endDate. It does not explain the accountId format or exact date semantics, but enough context exists for an agent to infer the parameter roles.

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'), a specific resource ('account-level analytics series'), and a clear scope ('connected social account', 'date range'). The 'account-level' qualifier distinguishes it from post-level analytics siblings such as get_post_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 when to use the tool (account-level analytics over a date range) but gives no explicit guidance about alternatives or when not to use it. It does not route the agent to siblings like get_post_analytics or get_follower_demographics, leaving the agent to infer the boundary.

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?

Annotations only show readOnlyHint=false, so the description carries the burden of explaining behavior. It reveals that the tool does not upload itself; it returns a presigned URL that the caller must PUT to, and that the resulting URL feeds create_post. It omits details like URL expiration or storage-host requirements, but covers the core non-obvious workflow.

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 short sentences, front-loaded with the primary condition and purpose, with no filler. Every sentence adds actionable 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?

Given two simple parameters and no output schema, the description covers the invocation workflow, the fallback path, and the downstream create_post usage. Missing only minor operational details such as presigned URL expiration or size limits.

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 should compensate. It never mentions filename or contentType, leaving their formats and constraints undocumented. The parameter names are self-explanatory, but no meaning is added beyond 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?

Description states a specific purpose: get a presigned URL for uploading media via HTTP PUT, then use it with create_post. It distinguishes itself from the sibling upload_media by calling itself the 'Preferred media path' for PUT-accessible runtimes.

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 says when to use this tool ('when you can HTTP PUT') and when not to ('If your runtime cannot reach the storage host ... call upload_media instead'). It also gives the exact sequence: PUT file bytes to the returned URL, then pass the public URL to create_post.

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 establish that the tool is read-Only and non-destructive, and the description adds useful context on top of that: a 50-pin limit, date-range scoping, metric-based ranking, and enrichment with SocialRobot publish data when available. It does not specify a default sort or output structure, but it goes beyond the annotation baseline.

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 focused sentences with no filler. The first sentence states the action, scope, and main constraint; the second adds data provenance and enrichment detail. The important information is front-loaded and 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?

This tool has four parameters, no parameter descriptions, and no output schema, so the description must compensate. It communicates the broad result concept but omits output shape, default ranking behavior, and parameter-level meaning, leaving enough ambiguity that an agent would need to infer or look elsewhere for invocation details.

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 carries the burden of explaining parameters, but it only mentions 'date range' and 'impressions or another metric' in general terms. It does not explain accountId, date format expectations, or the relevance of each sortBy enum value, so an agent gets little help beyond the raw 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 opens with a specific verb-resource statement: 'Return Pinterest account top pins' and adds concrete constraints: up to 50, date range, and ranking by impressions or another metric. This makes the tool's purpose immediately identifiable and distinguishes it from siblings like pinterest_list_boards 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 gives no guidance on when to use this tool versus close alternatives such as get_posts_with_analytics, get_post_analytics, or get_account_analytics. There is no explicit when-to-use, when-not-to-use, or alternative-selection advice.

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 establish this as read-only (readOnlyHint=true, destructiveHint=false), and the description adds that it returns 'raw' data and uses a 'platform-specific metric set,' telling the agent the output is unaggregated and varies by platform. It does n't disclose response format, error behavior, or permission requirements, but the safety profile is covered by 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?

A single sentence with each phrase carrying meaning: the action, the resource scope, the published constraint, and the platform-specificity. There is no filler or redundant re-statement 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?

The tool is a simple read-only getter with two parameters and an enum, and the description covers the core invocation context (single, published, platform-specific). However, with no output schema, it leaves the return structure unstated, and 'raw analytics' is vague about actual metric fields and shape.

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 implies targetId is a single published platform target and that platform affects the metric set, but does n't explain targetId format, required platform values beyond the enum, or how the two parameters combine. This is minimal compensation for an otherwise unannotated 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 clearly identifies a specific action ('Return') and resource ('raw analytics for a single published platform target'). It is distinct enough from get_account_analytics and get_posts_with_analytics because it specifies a single target, though it does n't name these 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 'single published platform target' gives implicit usage context: this is for one already-published post, not drafts or bulk analytics. There is no explicit when-not-to-use guidance or pointer to sibling tools, so guidance is inferred rather than 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?

The annotations already declare the read-only and non-destructive nature, so the description does not need to restate that. It adds some value by indicating the return composition: latest snapshot plus historical points, but it does not disclose pagination, date-range behavior, or any further constraints.

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 one concise sentence that front-loads the action and resource, then adds the distinguishing analytics detail. There is no redundancy or unnecessary verbiage.

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 five parameters, no output schema, and zero schema-level descriptions, this definition is too thin. An agent can infer the required platform and accountId, but it cannot fully understand the date-range mechanics, the limit parameter, or exactly how this result differs from list_posts. The read-only annotations reduce safety concerns but do not fill the comprehension 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 for the five parameters. It only loosely maps accountId to 'connected account' and platform/status to 'published posts'. The lifecycle of limit, startDate, and endDate is left entirely unexplained.

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 action ('List'), resource ('published posts'), and differentiating scope ('with their latest analytics snapshot and historical points') for a connected account. It is distinguishable from the sibling list_posts by the addition of analytics, though it does not explicitly name that alternative.

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 guidance is given about when to use this tool instead of list_posts or get_post_analytics. The phrase 'for a connected account' implies a precondition, but no alternatives, exclusions, or decision criteria are provided.

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?

With readOnlyHint=true and destructiveHint=false from annotations, the safety profile is already covered. The description adds meaningful behavioral context beyond the annotations: it reveals an external dependency ('Search Binging geo locations'), specifies how the output should be wired into create_post, and discloses an account/follower eligibility requirement. This is more than the minimum needed for a 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?

Three sentences, each earning its place: the first states the core action, the second shows integration, the third states a prerequisite. No redundant or filler content, and the essential purpose is front-loaded in the opening words.

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 tool has no output schema, so the description should convey what the tool returns, and it does by mentioning the 'returned urn + displayText.' It also covers the use case and eligibility requirements. It stops short of describing pagination, error cases, or the exact return shape, but for a read-only search utility that feeds create_post, the description is largely 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?

The input schema has no parameter descriptions, so the description must compensate. It indirectly clarifies that 'query' is a location search term through 'Search Bing geo locations' and hints that accountId is related to the required 'Company Page account.' However, it does not explicitly map accountId to the Company Page account or explain the expected query format beyond its schema constraints. This is adequate but leaves gaps.

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 and resource: 'Search Bing geo locations.' It grounds the purpose in a concrete use case, 'for LinkedIn Company Page organic targeting,' and distinguishes this tool from its siblings (linkedin_search_organizations, linkedin_search_people_mentions) by focusing on geo locations rather than organizations or people mentions.

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 states when to use the tool by explaining how the output is consumed: 'Pass returned urn + displayText into linkedinTargets[].post.geoLocations on create_post.' It also gives a prerequisite and constraint: 'Requires a Comppany Page account; LinkedIn needs more than 300 matching Page followers.' It doesn't explicitly mention alternatives or when-not-to-use, but the intended workflow is clear from context.

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, so the agent knows this is a safe read operation. The description adds value by specifying that it returns only accounts available to the authenticated user, but does not disclose return format, pagination, or other behavioral traits.

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, concise sentence that states the action, resource, and scope without redundant wording. It is immediately readable and front-loaded with the key 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?

Given the zero-parameter input schema and the safety profile already covered by annotations, the description provides enough information for an agent to select and invoke this tool correctly. No return-format detail is strictly necessary for such a simple list operation.

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 accepts zero parameters, and the description accurately reflects that the operation requires no input. The description also clarifies that results are scoped the authenticated user, which aligns with the empty 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 uses a specific verb ('List'), identifies the resource ('connected social accounts'), and scopes it to the authenticated user. It clearly distinguishes this tool from siblings like list_posts and pinterest_list_boards by naming the exact resource type.

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 clearly implies when to use this tool (to retrieve the user's connected accounts), but it provides no explicit guidance about when not to use it or how it compares to alternatives. Usage is inferred from the purpose rather than stated directly.

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 safe read-only nature is covered. The description adds context that the data is scoped to the authenticated user’s posts, but it does not disclose pagination behavior, response shape, or how the status values map to returned data. This adds some value beyond annotations without contradiction.

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 concise sentence with no filler, and it front-loads the core purpose. It is efficiently written, though it sacrifices useful detail for brevity.

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 optional filter parameters, no output schema, and no explanation of response structure or pagination, the single-sentence description is not enough for an agent to use filters with confidence. Annotations cover safety but not the operational details needed for correct 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%, and the description provides no explanation of any of the seven parameters. The agent is left without guidance on what sort values mean, how cursor pagination works, how dateFrom/dateTo interact, or what status/platform filters do. The description completely fails to compensate for the empty parameter 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 clearly states a specific verb ('List') and resource ('authenticated user’s scheduled, draft, publishing, or published posts'), so the basic purpose is evident. However, it does not explicitly distinguish this from sibling get_posts_with_analytics, which also appears to list posts, so some sibling differentiation is missing.

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 about when to use list_posts versus alternatives such as get_posts_with_analytics or get_post_analytics. The description does not mention filtering, pagination, or any context in which this tool should be preferred. Usage must be inferred entirely from the tool name and sibling list.

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 write operation and not destructive. The description adds some context by requiring a 'connected Pinterest account', but does not disclose side effects, defaults, duplicate handling, or external behavior. It 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 a single clear, front-loaded sentence. It wastes no words and communicates the core operation 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?

For a create tool with no output schema, the description is under-specified. It does not explain what happens after creation, whether the created board is returned, default privacy behavior, or failure scenarios. The schema covers required fields, but the description leaves important operational context missing.

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 0% schema description coverage, the description must compensate, but it only hints at accountId via 'connected Pinterest account' and name via 'board'. It provides no meaningful guidance on privacy, description, or how these fields interrelate.

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 and resource: 'Create a new Pinterest board for a connected Pinterest account.' It clearly distinguishes this from sibling tools like pinterest_list_boards by emphasizing creation rather than listing.

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?

Usage is implied by the verb 'Create', and the phrase 'connected Pinterest account' hints at a prerequisite. However, the description does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it or any fallback options.

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 already mark it as a mutation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds that the new date must be in the future, which is useful, but it does not disclose side effects such as cancellation of the old schedule, validation rules, or idempotency.

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 no filler; the core operation and constraint ('future') are front-loaded. Every word 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?

For a two-parameter mutation with no output schema and no enum documentation, the description is too thin to allow reliable invocation: an agent still lacks the scheduledFor format and any behavior around the original schedule. The low parameter coverage and absent usage guidance make this incomplete despite the simple surface.

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% and both parameters are bare strings, so the description must carry the semantics. It implies id is the existing post and scheduledFor is the new future date, but it does not specify the expected date format, timezone, or whether id is a post ID rather than a scheduling entry ID.

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 ('Move an existing post') with a clear target state ('a new future publication date'), so an agent can tell this reschedules rather than creates or deletes. It does not explicitly contrast with update_post, which may also edit scheduling fields, so it loses a point on sibling differentiation.

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 no guidance on when to choose reschedule_post over update_post or the other post-management siblings. There is no mention of prerequisites, constraints, or when not to use this tool.

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 already indicate destructiveHint=true, and the description aligns by using 'Replace'. It goes beyond annotations by disclosing important behavioral specifics: passing existing R2 media URLs is required to preserve assets, and passing an ordered segments array for X/Threads replaces the whole thread chain. These are non-obvious behaviors that an agent must know to call the tool correctly. It does not cover every side effect (e.g., whether omitting a platform target removes it), but the key destructive nuances are disclosed.

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, front-loaded with the purpose, and each sentence earns its place. The first sentence states the action and scope, the second gives a critical asset-preservation rule, and the third handles the complex thread-chain case. No fluff or repetition.

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 tool has 11 parameters and complex nested structures for eight platform targets, yet the description is brief. It explains the two trickiest behaviors (unchanged media and thread segments) but does not clarify whether the update is full or partial for platform targets—i.e., whether omitting a target removes it. This ambiguity could lead an agent to incorrectly update a post by passing only the fields it wants to change. More explicit guidance on the update semantics would be needed for 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?

Schema description coverage is 0%, so the description must carry the semantic burden. It adds meaning beyond the schema by explaining the concept of unchanged R2 media URLs and the ordered segments array for X/Threads, which are the most complex and error-prone parameters. It does not elaborate on every parameter, but many (e.g., scheduledFor, target arrays) are self-explanatory from their names and the schema structure. The description provides enough guidance for the critical decision 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 uses a specific verb 'Replace' and names the resource 'existing draft or scheduled post', and lists the fields that can be updated (caption, media URLs, schedule, platform targets). It clearly distinguishes this tool from create_post, delete_post, and reschedule_post by focusing on modifying an existing 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 its use case: modifying existing posts (draft or scheduled). It doesn't explicitly state when not to use it or name alternatives, but the sibling list and the phrase 'existing draft or scheduled post' provide clear context. It also gives specific guidance on how to handle unchanged assets and thread segments, which is practical usage direction.

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 are minimal (readOnlyHint false, destructiveHint false), so the description carries the burden. It discloses that SocialRobot fetches the bytes and stores them, which is a write operation, and that it returns a permanent URL. It also mentions the 50MB size limit. While it doesn't detail error handling or side effects, it covers the core behavior without contradicting 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 concise yet packed with essential info: purpose, fallback context, input options, processing, output, preference, and size limit. Each sentence earns its place, with the core purpose front-loaded. No fluff 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?

The tool has no output schema, so the description must explain the return value, which it does ('returns the permanent url for create_post'). It also integrates with siblings get_media_upload_url and create_post, placing it in the workflow. It mentions the max file size. Missing details like error handling or parameter precedence are minor for a fallback tool with optional parameters. Overall, it is sufficiently complete for an agent to use 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%, so the description must explain parameters. It clarifies that 'file' is a ChatGPT file (object or array) and that 'sourceUrl' is a public https URL. It does not explicitly explain 'filename' and 'contentType', but these are optional and reasonably inferable. The description adds meaningful semantics for the key parameters, compensating for the lack of schema descriptions.

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 purpose: a fallback uploader that fetches bytes from a ChatGPT file or public URL and stores them, returning a permanent URL for use with create_post. It explicitly distinguishes itself from get_media_upload_url, which is the preferred direct PUT method. The verb 'upload' plus resource 'media' and the fallback context make 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 description explicitly says when to use this tool ('Fallback when you cannot PUT to the presigned URL') and when not to ('Prefer get_media_upload_url when you can PUT'). It also states the output is intended for create_post, guiding the agent on the proper workflow. This is clear, actionable guidance with a named alternative.

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