SocialRobot MCP Server

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

Annotations declare readOnlyHint=false (mutation expected) and destructiveHint=false (non-destructive), so the description's 'Create' is consistent with annotations. The description adds important behavioral detail about TikTok's two publishing modes, including that UPLOAD creates an inbox draft to be finished in the TikTok app, and that X/Threads threads are posted as chained replies. However, it does not disclose scheduling semantics (e.g., date format, timezone), limits, or error behavior beyond what the schema already shows.

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 compact multi-sentence paragraph that front-loads the core purpose first, then adds targeted platform-specific detail. Every sentence earns its place: the first states the primary function, and the following sentences address non-obvious platform behaviors. It is appropriately sized for a complex multi-network scheduling 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?

The tool has a very large schema with 10 required top-level parameters and many nested options, but no output schema. The description correctly focuses on the cross-cutting behaviors that are non-obvious from the schema, such as TikTok's two publishing modes and thread building. However, it lacks guidance on how to structure the scheduledFor variants (DRAFT/NOW/SCHEDULE with date), which is required and not obvious from a large schema. It also doesn't clarify whether an empty targets array is meaningful or how to use the array-of-targets structure with sibling tools.

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 does add value: it explains the scheduledFor concept ('scheduled item'), the meaning of TikTok postMode values (DIRECT_POST vs UPLOAD), and the segments array behavior for X/Threads thread publishing. It doesn't enumerate all target array parameters or confirm the required nature of all target arrays, but it explains the most complex cross-network semantics. Given 10 required params with zero schema descriptions, the description meaningfully aids parameter invocation.

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: create a scheduled item that publishes to one or more connected social accounts. It uses a specific verb ('create') and resource ('scheduled item'), and its multi-network publishing scope distinguishes it from siblings like list_posts or delete_post. It also covers TikTok post mode nuances that clarify what the tool does for specific targets.

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 a clear context for when to use the tool (creating scheduled posts across social accounts) and includes usage guidance for TikTok's DIRECT_POST vs UPLOAD modes. It does not explicitly name alternative tools or say when not to use this tool versus siblings like update_post or reschedule_post, but the context is clear enough for an agent to select it 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 indicate destructiveness, and the description adds an authorization constraint: only posts belonging to the authenticated user are eligible. It clarifies the target state (draft/scheduled) without contradicting the annotation's destructiveHint.

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, front-loaded sentence contains the essential action, scope, and ownership restrition without any filler. This is appropriately concise for a simple one-parameter mutation 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 simple delete operation, the description covers the core action and ownership. However, with no output schema and no parameter definition, it leaves the id parameter and responese behavior to inference, which is a real but minor gap in a low-complexity 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 description coverage is 0%, and the description does not explain the id parameter at all. An agent must infer that id is the post identifier from the tool name and context, but no explicit guidance or format is provided.

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 action and resource: deleting a post. It also narrows scope with 'draft or scheduled' and ownership with 'belongs to the authenticated user,' which clearly differentiates it from sibling tools like create_post, update_post, and schedule_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 the tool is for drafts or scheduled posts and for the user's own posts, providing some context. However, it does not explicitly state when not to use it or mention alternatives such as update_post for published posts.

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?

Annotations already establish read-only, non-destructive behavior. The description adds useful platform-specific behavior, especially the LinkedIn Company Pages lifetime demographics detail, but it does not disclose pagination, data freshness, or behavior for unsupported platforms. This is acceptable 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 two tight sentences with no filler. It front-loads the primary action and then adds platform-specific detail, making it easy to scan.

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 four parameters, the description is not enough for an agent to confidently invoke the tool. It lacks guidance on how `breakdown` changes the response, what `locale` does, and what the actual return shape looks like.

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 mentions demographic dimensions like country, seniority, and industry, but does not explain the `breakdown`, `locale`, or `accountId` parameters or how they map to the returned data.

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 returns audience demographics for a connected social account, naming the specific resources (followers, LinkedIn Company Pages) and platforms. This distinguishes it from sibling analytics tools like get_account_analytics or get_post_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: when audience or follower demographic data is needed for supported platforms. However, it does not explicitly state when not to use it or mention alternatives such as get_account_analytics for general 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 adds meaningful behavioral context beyond the annotations: the tool returns a presigned URL rather than uploading directly, requires the caller to PUT file bytes, and depends on storage host reachability. It also states the follow-up step of passing the URL into create_post, which is valuable context the annotations do not 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 three sentences with each one earning its place: the primary use case, the exact upload workflow, and the fallback alternative. It is front-loaded with the key decision and contains 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?

For this tool, the description is functionally complete: it tells the agent what the tool returns, what to do with that return value, and when to choose a different tool. The two required parameters are simple enough that schema validation covers them, and no output schema exists to require return-value documentation.

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 provides no descriptions and the description does not explicitly explain the filename and contentType parameters. The parameter names are somewhat self-explanatory, but there is no detail on expected formats, MIME types, or naming constraints. With 0% schema coverage, the description should have compensated with at least brief parameter 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 clearly identifies the tool's function: obtain a presigned URL for uploading media via HTTP PUT. It distinguishes this from upload_media by explicitly labeling it the preferred path when HTTP PUT is possible, so an agent can immediately tell the two siblings apart.

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 guidance is explicit: use this tool when your runtime can HTTP PUT, then PUT the file bytes and pass the returned public URL to create_post. It also names the fallback alternative, upload_media, when the storage host is unreachable, which fully covers the when-to-use decision.

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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful context that results are personalized and based on past post performance, but it does not disclose output format, freshness of data, or any calculation nuances. 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?

The description is a single sentence that leads with the main outcome and includes the key qualifiers. Every word adds value, and there is no redundant phrasing.

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 low complexity—one self-explanatory parameter, no nested objects, no output schema, and annotations covering safety—the description is largely sufficient for correct invocation. It could be improved by briefly stating what the returned guidance looks like, but this is a minor gap for such a focused 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 description coverage is 0%, so the description must compensate. It clarifies that accountId refers to a 'connected Instagram account', which adds slight meaning beyond the bare parameter name and type. However, it does not explain where to find the accountId, what format is expected, or what happens if it is invalid.

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'), a clear resource ('personalized best-posting-time guidance for a connected Instagram account'), and the basis ('based on past post performance'). This clearly distinguishes it from sibling analytics tools like get_account_analytics and get_post_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 this tool—when the agent needs posting-time recommendations derived from performance history—but it does not explicitly mention alternatives or exclusion criteria. No guidance is given about when a sibling tool would be more appropriate.

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 mark the tool as read-only and non-destructive, so the description does not need to restate safety. It adds valuable behavior: the query-omitted fallback to 'Your Pages', compatibility with personal and Company Page compose, and the auth requirement of a connected Page CM token. These details give an agent meaningful operational expectations beyond the structured 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 packed sentences with no fluff: the first sentence states the core action and scope, the second gives auth/context, and the third gives concrete integration guidance. The most important information is front-loaded, and every sentence adds operational value.

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 lookup tool with no output schema, the description covers the purpose, optional-query behavior, auth prerequiste, and how to consume the result in create_post. The only notable gap is the lack of explicit accountId semantics and return-shape details, but the description is strong enough that an agent can likely call it correctly after connecting a LinkedIn account.

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 two parameters, query and accountId, but the description only indirectly indicates that query is optional ('when query is omitted') and never explains accountId's meaning or role. The mention of 'type, urn, displaText' refers to create_post fields, not to this tool's parameters. With low parameter coverage in the description, the agent is left to infer the meaning of the required accountId from the tool name and sibling context.

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 ('Resolve LinkedIn companies for @mentions') and a specific mechanism ('vanity Organization Lookup'), which clearly distinguishes it from sibling tools like linkedin_search_people_mentions and linkedin_search_geo_locations. It also adds the useful nuance that omitting the query resolves 'Your Pages'. This is a precise, non-tautological purpose statement.

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 explains when to use the tool: when composing a personal or Company Page post/comment and needing LinkedIn company @mentions. It also provides a prerequiste ('needs any connected Page CM token') and shows how to feed the result into create_post via captionMentions/firstCommentMentions. It does not explicitly list alternatives or exclusion cases, so it stops short of a fully explicit routing guideline.

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 useful scope constraints ('Company Pages only') and a matching requirement (start/length must match the plain caption/firstComment span), but it does not disclose query behavior, pagination, authentication, or result 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?

Two sentences, front-loaded with the core purpose. The second sentence is dense but contains critical downstream usage guidance. No filler or repeated schema info.

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 minimal parameter metadata, the description carries a heavy burden. It gives the core action and a downstream tip but is missing essential context about what the query searches, what the response contains, and how results are paginated or limited.

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 two required parameters (accountId, query) with no descriptions. The description only loosely implies accountId identifies a Company Page and query searches for mentions; it does not explain what the query matches against, allowed values, or how the mentioned 'type, urn, displayText' fields relate to the request 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?

States a specific verb ('Search') and resource ('Page followers for LinkedIn @mentions'), with an explicit scope ('Company Pages only'). This distinguishes it from sibling search tools such a linkedin_search_geo_locations and linkedin_search_organizations.

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 contextual guidance ('Company Pages only') and shows how to use the returned data by passing type, urn, displayText into captionMentions or firstCommentMentions on create_post. However, it does not explicitly state when to choose this tool over alternatives or name 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 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, so the sole behavioral trait (read-only retrieval) is covered. The description adds slight context about the account requirement but no details on pagination, rate limits, or return behavior. With annotations present, this is adequate.

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, front-loaded sentence that states the action and scope without wasted words. Perfectly sized for a simple read 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 tool with no output schema, the description covers the basics but omits return format details and any mention of what constitutes a 'connected' account. It's minimally complete but not deeply informative.

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 for the undocumented accountId parameter. The phrase 'for a connected Pinterest account' implies accountId identifies that account, but it doesn't explain how tos ource or format the value. Minimal compensation 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?

The description uses a specific verb ('Return') and a clear resource ('Pinterest boards'), scoped to a connected Pinterest account. This distinguishes it from siblings like list_posts and pinterest_create_board.

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 you need boards for a connected account) but gives no explicit guidance on alternatives or prerequisites, such as obtaining accountId from list_connected_accounts.

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 a mutating, non-destructve operation; the description adds that it moves the existing post and requires a future date, which is useful context. However, it does not disclose error behavior, timezone handling, or external side effects despite openWorldHint=true.

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 concise sentence with the action verb front-loaded, no redundant information, and every word contributes to meaning. It is appropriately sized for the tool's simplicity.

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 with annotations covering read-only/destructive flags, the description covers the main behavior adequately. It remains incomplete on exact parameter formats, return behavior, and any validation/failure semantics.

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 loosely maps id to 'existing post' and scheduledFor to 'future publication date'. It does not explain id format, date format, timezone, or required constraints between the two 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 uses a specific verb ('Move'), a clear resource ('an existing post'), and an explicit outcome ('to a new future publication date'). It clearly separates this from create/delete/list operations, but does not distinguish it from the similarly named update_post sibling.

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 when-to-use or when-not-to-use guidance is provided, and no alternative tools are referenced. The intended usage must be inferred entirely from the purpose statement rather than being explicitly 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the field-level return scope and the create_post dependency, but does not disclose any other behavioral details such as authorization requirements or potential errors. This is acceptable but not exceptional given the read-only annotation.

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, front-loaded with the core return information and followed by a concise usage instruction. Every sentence provides distinct value and there is no filler or redundant wording.

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 covers what the tool returns and when to call it. The main gap is that it does not specify where accountId comes from or link it to list_connected_accounts, which is relevant for an agent assembling a create_post workflow. Without an output schema, the listed fields help, but the parameter provenance remains under-specified.

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 0% description coverage for the single required accountId parameter. The description only says 'for an account,' which largely restates the parameter name and does not explain how to obtain the accountId or what format is expected. Since schema coverage is low, the description needs to compensate but only adds minimal 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 states a specific verb and resource: it returns TikTok creator fields such as nickname, avatar, privacy_level_options, interaction settings, max video duration, and posting limits. This clearly distinguishes it from sibling tools that handle posts or analytics. The tool name and description align without tautology.

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 'Use before create_post with tiktokTargets,' giving a concrete integration point and a clear when-to-use context. It does not formally list alternatives or when-not-to-use scenarios, so it doesn't quite earn a 5, but the guidance is actionable and clear.

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 signal it's a mutation (readOnlyHint=false) and non-destructive. The description adds real behavioral value beyond that: replace-not-merge semantics, the critical rule to pass existing R2 media URLs for unchanged assets, and the thread-chain replacement nuance for X/Threads (root stays segment 1). It stops short of stating whether an empty target array removes a platform target.

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 first fronts the action, the second delivers the media-reuse rule, the third covers the thread-chain exception. 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?

For a tool with 11 required params, deep nesting, and no output schema, the description surfaces the three operational traps that would most likely break an agent call: replace semantics, R2 URL reuse, and segment ordering. Gaps remain (empty-array removal behavior, the fact that all target arrays are required means callers must reconstruct the full target set), but the description is strong relative to the enormous complexity.

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 bears the full burden. It explains the two semantically tricky parameters classes — media URLs (reuse R2 URLs) and twitter/threads segments (ordered array replaces whole chain) — but 11 top-level required params and their deep nested structures (poll, visibility, transform, scheduledFor variants) receive no elucidation anywhere.

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 the specific verb 'Replace' and names the exact resource ('an existing draft or scheduled post') plus the editable fields: caption, media URLs, schedule, and platform targets. This clearly distinguishes update_post from siblings like create_post, delete_post, and reschedule_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 phrase 'existing draft or scheduled post' gives clear context for when to use the tool versus creating a new post, and implicitly excludes published posts. However, it never names alternatives explicitly or states conditions like 'use reschedule_post when only the date changes,' leaving some routing 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?

The description discloses the core behavior: SocialRobot fetches the bytes, stores them, and returns the permanent URL, plus the 50MB limit. Annotations are limited to safety signals, so this added behavioral context is valuable. It could mention failure modes or what happens when both file and sourceUrl are provided, but it is largely 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 and front-loaded. Every sentence contributes: fallback condition, payload options, behavior/result, preferred alternative, and size limit. There is no repetition of schema details or wasted wording.

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 an agent enough to decide when to call it, what to pass, what happens, and what is returned. It is slightly incomplete around optional metadata parameters and the exact mutual-exclusion contract, but the schema provides the structural details. Given the tool's complexity, this is a strong and usable definition.

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. It meaningfully explains that 'file' is a ChatGPT file and 'sourceUrl' is a public https URL, and implies they are alternatives. However, it leaves 'filename' and 'contentType' unexplained, and does not mention the array form of 'file' or the implied at-least-one-source requirement.

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 this tool uploads media as a fallback when PUT to the presigned URL from get_media_upload_url is not possible. It specifies what SocialRobot does with the bytes and that it returns a permanent URL for create_post, distinguishing it from related siblings.

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 guidance is explicit: use this tool when you cannot PUT to the presigned URL from get_media_upload_url, and prefer get_media_upload_url when PUT is possible. This gives the agent a clear decision rule for choosing between the two upload paths.

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