Publish to social channels from your AI agent. Threads is live; nine more await review.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.5/5 across 20 of 20 tools scored. Lowest: 3.8/5.
Most tools have distinct purposes (publish, delete, reply, list, etc.), but get_post and open_post overlap, as do list_posts and list_channel_posts. The descriptions do clarify when to use each, so confusion is limited but possible.
The majority follow a verb_noun pattern (delete_post, list_replies), but the media_* tools invert this (media_presign, media_complete) and publish/reply are bare verbs. This mixed style is readable but not fully consistent.
20 tools is on the higher end but each serves a distinct step in the publishing workflow, especially the five media tools covering different upload scenarios. The count feels justified by the platform's complexity.
The set covers posting, replying, reading, deleting, retrying, media upload, insights, and quota checks. Missing features like scheduling and post editing are explicitly not supported by the platform, so there are no significant gaps for the intended domain.
delete_postDelete a postADelete a post from the channel for good. This is not reversible, so confirm with the person first. Daily delete limits differ per channel: Threads 100 a day, YouTube 20 a day. Works on posts written in the channel's own app as well, given the link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint=true annotation, the description adds critical behavioral details: 'not reversible' clarifies the extent of destructiveness, 'daily delete limits differ per channel' discloses rate limiting, and 'Works on posts written in the channel's own app as well' expands the input scope. These are valuable context that annotations alone do not convey.
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, each earning its place: the first states the action, the second warns about reversibility and human confirmation, and the third adds rate limits and input scope. No filler or repetition; the most important information is front-loaded.
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 single-parameter destructive tool with annotations and no output schema, the description covers all essential aspects: what it does, irreversibility, rate limits, valid input types, and edge case (own-app posts). Nothing important is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides a thorough description of the 'id' parameter, including accepted formats (publish id, channel-side id, or link). The tool description adds only a brief reference to 'given the link' which is redundant with the schema. With 100% schema coverage, a baseline of 3 is appropriate; the description does not significantly enhance parameter understanding.
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: 'Delete a post from the channel for good.' This clearly distinguishes it from sibling tools like hide_reply (which hides a reply) and get_post (which retrieves). The phrase 'for good' reinforces permanence and sets it apart from temporary actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete situational guidance: confirm with the person first due to irreversibility, and notes daily limits per channel. It also clarifies that the tool works on posts from the channel's own app. However, it does not explicitly contrast with alternatives like hide_reply, so it stops short of a full when/when-not comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_insightsGet post metricsAViews, likes, replies, reposts, quotes and shares for one publish. Views and shares can be null when the platform does not report them yet — null is not zero.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the behavioral caveat that 'Views and shares can be null when the platform does not report them yet — null is not zero,' which is valuable beyond the readOnlyHint annotation. This clarifies a potentially confusing aspect of the return data.
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, information-dense sentence. It front-loads the metrics and immediately adds the null caveat without unnecessary 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?
Given the tool's simplicity (one parameter, no output schema), the description fully covers the return value by listing the metrics and the null behavior. It could be argued that an example would help, but the description is sufficient for an agent to anticipate the tool's behavior.
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 a thorough description of the id parameter, including accepted formats and edge cases. The tool description adds no additional parameter information, so the schema carries the full burden, yielding the baseline score of 3.
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 enumerates the metrics (views, likes, replies, reposts, quotes, shares) and scopes them to 'one publish', distinguishing this from sibling tools like get_post (which likely returns content) and list_posts (which lists multiple 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 description does not explicitly state when to use this tool over alternatives, but the purpose is so specific that usage is implied. No alternatives are mentioned, so it lacks the explicit guidance that would merit a 4 or 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_postGet one postAOne publish: per-target status and the reason any target failed. For a post link you probably want open_post instead.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint, and the description adds valuable behavioral context: the tool returns per-target status and failure reasons, and the id parameter tolerates publish ids, channel-side ids, and post links (including posts from the channel's own app if connected). 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 two concise sentences with no filler. The first sentence front-loads the core purpose, and the second gives an actionable alternative. 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 single-parameter read-only tool with a rich schema description, the description adequately covers response contents (per-target status, failure reason) and offers usage guidance. The absence of an output schema is not a gap because the response nature is described. Slight under-specification of when to use this vs list_posts or get_insights, but not critical.
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 already provides 100% coverage for the single parameter, with a detailed description of accepted id formats and connected-account caveats. The tool description adds no additional parameter meaning beyond what the schema provides, so baseline 3 applies.
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 it returns per-target status and failure reasons for a publish, which clearly identifies the tool's function. It also distinguishes itself from open_post for post links, adding sibling differentiation. However, the verb 'get' is implicit and the phrasing is a bit telegraphic.
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 advises using open_post instead when handling a post link, providing a clear alternative. It doesn't enumerate all scenarios but gives a key exclusion, which is useful guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_quotaGet remaining publishing quotaAHow much of the 24 hour allowance is already used for posts, replies and deletes. Check this before a burst of publishing. This is live usage from the platform, not the static limits in list_platforms. We also cap how fast one account can publish, so publish can return rate_limited even when the platform allowance still has room.
| Name | Required | Description | Default |
|---|---|---|---|
| accountId | No | Limit to one account. Omit to cover every connected channel. | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds valuable behavioral context: it reports live usage from the platform, and reveals an internal rate cap that can cause publish to fail independently of platform allowance. This goes beyond the basic read-only hint.
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?
Four sentences, each serving a clear purpose: function, usage timing, differentiation from static limits, and a caveat about rate limiting. No fluff or repetition, and the most important information is front-loaded.
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 could have specified the return format, but it clearly conveys the core measurement (used vs. allowance) and provides context for interpreting when rate limits might still occur. The absence of an output schema is partially compensated by the description's conceptual clarity, though a bit more detail on what is returned would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for both parameters, with clear descriptions in the schema itself. The description does not add parameter-specific semantics, so the baseline of 3 is appropriate; it does not need to compensate.
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 reports how much of the 24-hour publishing allowance is used for posts, replies, and deletes. It explicitly distinguishes itself from list_platforms by noting 'not the static limits in list_platforms', making the purpose specific and unambiguous relative to sibling tools.
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 explicit usage timing with 'Check this before a burst of publishing' and contrasts itself with list_platforms as the alternative for static limits. Also warns that publish can return rate_limited even when allowance remains, giving practical guidance for when to check quota.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
hide_replyHide a replyAHide a reply on the channel, or show it again with hide: false. The reply id comes from list_replies, and postId is the publish it belongs to.
| Name | Required | Description | Default |
|---|---|---|---|
| hide | No | true hides it, false shows it again. Defaults to true. | |
| postId | Yes | The post the reply sits under. A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. | |
| replyId | Yes | Reply id from list_replies |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations mark destructiveHint=true and readOnlyHint=false, but the description adds valuable transparency by noting the action is reversible with hide:false. It also clarifies the relationship between replyId and postId. This goes beyond the structured hints and helps the agent predict side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero filler. The first sentence front-loads the primary action and the toggle behavior; the second sentence concisely explains where to obtain the replyId and the role of postId. 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 simple toggle tool with three parameters and a good schema/annotations, the description covers purpose, key behavior (reversibility), and parameter origins. It does not state return values, but no output schema exists and this is a low-complexity action. The combination of description, schema, and annotations is sufficient 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 100%, so the baseline is 3. The description does not add much beyond the schema: 'reply id comes from list_replies' is redundant with the schema description for replyId, and 'postId is the publish it belongs to' repeats the schema's first sentence. No extra semantic value 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?
The description states a clear verb+resource: 'Hide a reply on the channel.' It also immediately adds the toggle behavior ('or show it again with hide: false'), which precisely defines the tool's function. This effectively distinguishes it from sibling delete_post (hide vs. delete).
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 tells when to use the tool (hide or show a reply) and provides a key context clue: the reply id comes from list_replies. It does not explicitly exclude alternatives or contrast with delete_post, but the guidance is clear enough for typical usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_accountsList connected accountsAConnected social accounts. Call this before publishing anything. Each item has id, platform (threads etc.), handle and status. The accountIds you pass to publish are these ids, and only "active" ones publish. If the person did not name a channel, target every active account. If the list is empty, no channel is connected yet. Send the person to https://uplika.com/dashboard/connections.
| Name | Required | Description | Default |
|---|---|---|---|
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds non-obvious behavioral context: the meaning of status 'active', that only active accounts are used for publishing, and that an empty list indicates no connected channel. This goes beyond the annotation without contradicting it.
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?
Every sentence adds value, starting with the core purpose, then usage context, output fields, and edge-case guidance. It is front-loaded and contains no redundancy or 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?
Despite lacking an output schema, the description explains the item fields and key statuses, integrates with the publish workflow, and covers the empty-list case with a suggested action. This is complete for a read-only list 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 description itself does not discuss the workspaceId parameter, but the schema provides a thorough parameter description including when it is needed and explicit guidance not to re-ask. With 100% schema coverage, the description adds little parameter-level meaning, earning the baseline 3.
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 lists connected social accounts, enumerating fields (id, platform, handle, status). It distinguishes itself from sibling tools by explicitly positioning it as the precursor to publishing, and it is uniquely named 'list_accounts' with no similar 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?
Explicitly instructs 'Call this before publishing anything' and explains how the output maps to publish (accountIds, only active accounts, targeting all active accounts when no channel is named). Also provides an actionable fallback when the list is empty, sending the person to the dashboard.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_channel_postsList posts on the channelAWhat is actually on the channel right now, including posts written in the channel's own app. Use this to find a post when you do not have its link. Each item carries a permalink you can pass straight to open_post, reply or delete_post.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1-100, defaults to 25 | |
| accountId | No | Limit to one account. Omit to cover every connected channel. | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description adds useful context beyond this: it includes posts from the channel's own app, and each item carries a permalink usable for other actions. 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 three sentences with no fluff. It opens with what the tool does, then provides a use case, then explains output behavior (permalinks). 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 read-only list tool with no output schema, the description covers the essential purpose, scoping, and output (permalinks). It does not mention pagination or other return fields, but the schema covers limit and the context is sufficient for tool selection and 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 100%, so the parameters (limit, accountId, workspaceId) are already fully documented. The description adds no extra parameter semantics, so the baseline score of 3 is appropriate.
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 lists posts on a channel, including posts from the channel's own app. It distinguishes from the sibling 'list_posts' by scoping to a specific channel and mentioning the inclusion of own-app 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 description says 'Use this to find a post when you do not have its link', which gives a clear usage condition. It also implies alternatives by mentioning open_post, reply, and delete_post, but does not explicitly state 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.
list_platformsList platform limitsAEvery channel and its rules: character limit, whether media is required, image and video limits, and what state the channel is in. Read this instead of guessing a platform's limits. status is one of three: live means anyone can connect; beta means the channel is in platform review and only accounts registered as testers on our app can connect yet, though publishing works normally for those accounts; soon means it is not connectable at all. charCount tells you how that channel counts a character, so you can check the length before calling publish instead of after it fails.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description explains status values (live, beta, soon) and charCount semantics, which are important behavioral details. It also reassures that beta channels can publish but only testers can connect, adding value.
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 front-loaded with the core function, then adds use-case guidance and status/charCount explanations. Each sentence adds meaningful context without fluff.
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 covers the essential output aspects: channel rules, status meanings, and charCount usage. It fully compensates for the lack of structured output 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 tool takes no parameters, so the schema is empty. The description focuses on output semantics (status, charCount), which is the relevant information for an agent; baseline 4 is appropriate.
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 lists every channel and its rules (character limit, media requirements, status). This is distinct from sibling tools that manage posts or accounts, so the scope is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It tells the agent to read this before calling publish to check limits, providing a specific when-to-use scenario. It doesn't explicitly name alternative tools, but the context strongly implies it complements publishing operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_postsList posts published hereARecent publishes made through us and the per-target status of each. Newest first, 20 by default. Pass limit for more or fewer, up to 100. hasMore means the list was cut short; pass the returned nextBefore as before to keep going. Posts that already existed on the channel are not here. Use list_channel_posts for those.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 1-100, defaults to 20 | |
| before | No | A publish id from a previous page's nextBefore. Returns the ones older than it. | |
| status | No | Narrow to one status: publishing, published, partial, failed or cancelled. Omit for everything. | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description reveals key behavior: newest-first ordering, a default limit of 20 with a max of 100, pagination semantics (hasMore and nextBefore), and the exclusion of pre-existing channel posts. This gives the agent a strong mental model of how the tool behaves.
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 four concise sentences, front-loaded with the main purpose and followed by necessary behavioral details. Every sentence adds value with 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 4 parameters and no output schema, but the description covers the core behavior, pagination, limits, scope, and an alternative. It provides enough context to invoke the tool correctly without needing additional explanation.
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 100%, so baseline is 3. The description adds value by explaining the limit default and range, and how to use before with the returned nextBefore for pagination. It does not re-explain workspaceId, but the schema already covers that well.
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 lists recent publishes made through the service, with per-target status, and explicitly distinguishes itself from list_channel_posts by noting pre-existing channel posts are excluded. This gives a specific verb, resource, and scope while differentiating from a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: when to use (for publishes made through the service), how to paginate using hasMore and nextBefore, and an explicit alternative (use list_channel_posts for pre-existing channel posts). It covers both when and when-not more clearly than most tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_repliesList replies to a postAThe whole reply thread under a post, nested replies included. truncated tells you we stopped before the end. The count here can differ from the replies metric in get_insights, which is normal.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds beyond that: it discloses pagination-like behavior via the 'truncated' flag and clarifies that the reply count may differ from get_insights. This gives the agent a heads-up about incomplete results and metric inconsistencies, which is valuable context not captured in annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each with a purpose: stating the core function, explaining the 'truncated' field, and clarifying a potential count mismatch. No fluff or redundancy. Front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential behavior (nested replies, truncation, count differences) given the simple parameter set and read-only nature. It does not detail the exact fields in each reply object, but for a listing tool that's likely acceptable. It's nearly complete, with only the return structure left unspecified.
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 covers 100% of parameter descriptions, including details about accepted id formats (publish id, channel-side id, post link). The description adds no parameter-specific information beyond what the schema provides, so a baseline of 3 is appropriate per the rubric.
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 it returns 'the whole reply thread under a post, nested replies included,' which is a specific verb (list) and resource (reply thread). It distinguishes from sibling tools like list_posts or get_post by emphasizing nested replies, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context on when to use this tool: to see the full reply thread including nested replies. It also references get_insights to explain a count discrepancy, offering a behavioral comparison. However, it doesn't explicitly mention alternatives like get_post for single post retrieval, so it's not a full when/when-not guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
media_completeFinish an image uploadAInspectStep 2 of attaching an image. Call it after the upload finishes. We check the file really landed before marking it ready. Only a ready media id can be passed to publish.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Media id from media_presign |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate it is neither read-only nor destructive. The description adds that the tool verifies the file landed and flips the media to a ready state, which is useful. However, it lacks details on failure behavior, idempotency, or consequences of premature invocation, leaving some gap.
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 short sentences, each adding distinct value: context, usage timing, and behavioral outcome. No redundant wording or restating of the tool name; it is front-loaded 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?
With 1 parameter, no output schema, and basic annotations, the description provides the core context: what, when, and effect. However, it omits mention of return values or error handling, which is a noticeable gap for a state-changing API. It is 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 full coverage (100%) for the single parameter 'id' with description 'Media id from media_presign'. The description reinforces the source of the id by referencing step 2 and media_presign in the schema, but adds no new parameter-level detail beyond the schema, so it rests at the baseline.
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 this as 'Step 2 of attaching an image' with a specific role: finalizing the upload and marking the media ready. It distinguishes from siblings by its position in the sequence (after upload, before publish) and includes a concrete verb phrase 'check the file really landed before marking it ready.'
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 gives explicit when-to-use guidance ('Call it after the upload finishes') and a prerequisite ('Only a ready media id can be passed to publish'). It does not explicitly compare with alternative steps like media_upload_status, but the sequential framing provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
media_from_urlAdd media from a public URLAInspectAttach an image or video that is already on the public web. We download it, copy it into our storage and give you a media id you can pass to publish. One step, no upload needed. https only. Google Drive and Dropbox share links do not work: they return an HTML preview page, not the file. Use a direct file URL that ends in the file itself. If you can see the image, write altText describing it.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public https URL of the image or video file itself. | |
| altText | No | What the image shows, for people using screen readers. Applied to carousel items. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool downloads, copies into storage, and returns a media ID. It also mentions constraints (https only) and failure modes (share links return HTML, not files). This gives the agent a clear behavioral model.
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, starting with the core action. It uses 7 sentences but each adds value: main function, internal process, output, one-step nature, protocol restriction, failure case, and altText guidance. Slightly long but all content is pertinent and well-structured.
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 that downloads external media, the description covers prerequisites (public, https, direct URL), the process (download, copy, return media id), and a common failure scenario. It also clarifies how this differs from sibling upload tools. Without an output schema, the description still conveys what the agent receives (a media id).
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 already covers both parameters (url, altText) with descriptions, so baseline is 3. The description adds extra semantics: explains that the URL must be the direct file path, not a share link, and advises writing altText if an image is visible. This goes beyond the schema's literal 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 function: attaching an image or video from a public URL by downloading it into storage and providing a media ID for publishing. It uses a specific verb ('Attach') and resource ('media from URL'), and distinguishes itself from sibling upload tools like media_upload_link.
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 explicit when-to-use guidance: for public web media that can be directly fetched. It gives exclusions ('Google Drive and Dropbox share links do not work') and a rule of thumb ('Use a direct file URL that ends in the file itself'). Also instructs when to add altText, which is practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
media_presignStart a direct image uploadAInspectStep 1 of attaching an image or video. Returns a media id and a one-time uploadUrl. PUT the file bytes to uploadUrl with the same contentType, then call media_complete. Images: image/jpeg, image/png, up to 8MB. Video: video/mp4, video/quicktime, up to 1GB, 300 seconds, 1920px wide. Aspect ratio up to 10:1. Any image pixel width is fine. If you can see the image, write altText describing it. The response has mediaExpiresAt: this media id disappears after that time if it was never published, and publish will then fail with media_expired.
| Name | Required | Description | Default |
|---|---|---|---|
| bytes | Yes | File size in bytes | |
| width | No | Pixel width, if you know it | |
| height | No | Pixel height, if you know it | |
| altText | No | What the image shows, for people using screen readers. Write it whenever you can see the image. Applied to carousel items. | |
| fileName | Yes | ||
| contentType | Yes | image/jpeg or image/png or video/mp4 or video/quicktime | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behavioral details beyond annotations: the uploadUrl is one-time, the media id expires after mediaExpiresAt, and publish fails with media_expired if never published. It also specifies upload limits and altText guidance, making the tool's behavior highly 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 well-structured and front-loaded: it starts with the tool's role and immediate output, then flows logically through the upload steps, constraints, altText guidance, and expiry behavior. Every sentence adds value, and nothing is redundant or fluff.
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 lack of an output schema, the description thoroughly explains the return values (media id, uploadUrl, mediaExpiresAt) and the overall workflow. It covers step-by-step instructions, limits, and error conditions, making it complete for an agent to invoke the tool 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?
While the schema already covers most parameters (86% coverage), the description adds meaningful semantic details: the contentType must match when PUTting bytes, altText should be written if the image is visible, and workspaceId is only needed when the account has multiple workspaces. These go beyond the 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 'Step 1 of attaching an image or video' and identifies the specific resource ('direct image upload') and action (returns a media id and a one-time uploadUrl). It distinguishes itself from sibling tools like media_complete and media_from_url by framing it as the initial step in a direct upload workflow.
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 clear usage context: it is the first step for direct uploads, instructs to PUT bytes to uploadUrl, and explicitly directs users to call media_complete next. It also includes file type and size constraints that help decide when this tool is appropriate. However, it does not explicitly contrast with alternatives like media_from_url or media_upload_link.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
media_upload_linkCreate an upload linkAInspectAsk the person to upload files from their own device. Returns a short-lived link. Give the link to the person, then wait. Poll media_upload_status with the token until it returns ready, and only then call publish with the media ids it gives you. Do not publish before the status is ready. Use this when the file is on their computer or phone; use media_from_url when the file already has a public https address.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | One line shown on the upload page, e.g. what you need them to upload. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=false and destructiveHint=false, so the description carries the burden of explaining behavior. It discloses the short-lived nature of the link, the need to poll media_upload_status with the token, and the sequencing/dependency on publish. This goes beyond annotations and helps the agent understand the tool's non-trivial behavior, though it doesn't cover failure modes or exact token 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 well-structured: it starts with the core action, then provides the workflow, a caution, and an alternative. Every sentence adds necessary information without fluff, making it efficient and easy to parse.
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 convey return values and usage context. It mentions the link and the token, explains the follow-up status polling, and differentiates from a sibling tool. It is sufficiently complete for a simple one-parameter tool, though it could mention the lack of a return schema explicitly, but the context is clear.
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 fully describes the only parameter (note) with 100% coverage, so the description doesn't need to add extra parameter details. The description adds no additional semantic value beyond what the schema provides, resulting in a baseline score of 3.
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: asking the person to upload files and returning a short-lived link. It explicitly distinguishes itself from media_from_url, so it's easy to identify when to use this tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage guidance: use it when the file is on the person's device, and use media_from_url when the file has a public https address. It also explains the full workflow (give link, wait, poll status, then publish), including the caution not to publish before ready.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
media_upload_statusCheck upload statusAHas the person uploaded yet? Returns waiting, ready or expired, plus every media id uploaded through that link. Pass those ids to publish as mediaIds.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | The token from media_upload_link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes this as a safe read operation. The description adds valuable context about the possible return statuses (waiting, ready, expired) and how the returned media IDs can be passed to publish, which goes beyond the 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 with no filler. The first sentence immediately states the core purpose and output, and the second sentence provides actionable guidance, making it highly 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 tool with one parameter and no output schema, the description fully covers the return values (statuses and media IDs) and their downstream usage. It omits only edge-case details like what 'expired' means operationally, but the essentials are present.
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 100% and the token parameter is described as coming from media_upload_link. The description reinforces this by referring to 'that link' and explaining the token's role, but it doesn't add substantial new meaning 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 clearly states the tool's function as checking upload status, enumerates the possible statuses (waiting, ready, expired), and mentions that it returns media IDs. It also implicitly distinguishes itself from siblings like media_upload_link and media_complete by focusing on status checking and providing next-step guidance.
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 a clear workflow: use this tool to check whether an upload has occurred via a link, then use the returned media IDs in a publish call. While it doesn't explicitly state when not to use it, the context and sibling list make the use case unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
open_postOpen a post with replies and metricsAEverything about one post in a single call: the text, the whole reply thread, and its metrics. This is the right tool when someone hands you a post link. Replies or metrics can come back null if the platform refused just that part.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that replies or metrics may return null if the platform refuses that part, which adds behavioral context beyond the readOnlyHint annotation. It does not contradict the annotations and provides practical information about partial failures.
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 only two sentences, front-loaded with the core purpose, followed by a usage hint and a caveat. Every sentence earns its place, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only tool with a rich schema and no output schema, the description covers the returned components and a key failure mode. It lacks detailed output structure, but the high-level overview is sufficient for an AI agent to select and invoke the tool effectively.
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 already fully documents the id parameter, including acceptable formats (publish id, channel-side id, post link) and link resolution behavior. The tool description adds no extra parameter-level detail, so the baseline score of 3 is appropriate.
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 function: retrieving the post text, full reply thread, and metrics in a single call. It distinguishes itself from sibling tools like get_post and list_replies by emphasizing the comprehensive, combined nature.
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 an explicit trigger scenario: 'This is the right tool when someone hands you a post link.' It implies this replaces separate calls for post, replies, and metrics, but does not explicitly mention alternatives or exclusions, leaving a small gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
publishPublish a postAPost to social channels. Channels open today: threads, youtube. Get accountIds from select_channels — do not guess which channel the person meant. Text limits differ per channel: Threads 500 characters, YouTube 5000 UTF-8 bytes. Over the limit nothing goes out to any channel, so shorten it before calling. Images and video both work on the channels that take them, and a carousel can mix them. YouTube is different: it takes exactly one video, no images, and it needs options.youtube.title. Its description is measured in UTF-8 bytes, so Korean and Japanese cost three per character. There are three ways to get a media id, pick by where the file is: media_from_url when it already has a public https address, media_upload_link when it is on the person's own device, media_presign plus media_complete when you can PUT the bytes yourself. Then pass the media ids here. This publishes immediately on every channel except YouTube, which can be scheduled with options.youtube.publishAt while privacyStatus is private. If the user asks to schedule anywhere else, tell them uplika cannot do that yet. A YouTube video published before Google finishes reviewing this app is locked to private viewing, so say that when you report a YouTube post as done. Returns while the post is still publishing. The permalink is null at that moment. Call get_post with the returned id to see the final status and link. Pass wait: true to hold the response until it is really out — then you can tell the person it is posted instead of guessing. For a long post use threadItems instead of publish-then-reply: we keep the order and wait for each piece to land before sending the next one.
| Name | Required | Description | Default |
|---|---|---|---|
| wait | No | Hold the response until the post is really out. Text waits up to 10 seconds, posts with media up to 90 seconds. If it is still going after that you get the usual publishing response and should poll get_post. Defaults to false. | |
| content | No | Post text | |
| options | No | Per-channel settings. Only the channels you are posting to need an entry. | |
| mediaIds | No | Media ids from media_presign, each already confirmed with media_complete | |
| topicTag | No | One topic to tag the post with, like a category. Only some channels take one, and those reject periods and ampersands in it. If any channel in accountIds does not take topics the whole call is refused, so publish to it separately. On a thread it goes on the first piece only. Leave it out unless the person asked for a topic. | |
| accountIds | Yes | Account ids from select_channels | |
| threadItems | No | Split a long post into a chain instead of calling publish and then reply. The first item is the root and the rest become replies under it, in order. We handle the ordering and the waiting. Each item obeys the character limit on its own. Pass either content or threadItems, not both. If a later item fails, the ones already up stay up and the response tells you where to resume. | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint annotation, the description discloses key behavior: publishing is asynchronous (returns before complete, permalink is null), posts fail entirely if over character limit, YouTube uploads are forced private before app review, and scheduling only works on YouTube with publishAt. This gives the agent a clear mental model of side effects and caveats.
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 long but appropriately sized for a tool with eight parameters, nested options, and many channel-specific exceptions. It is front-loaded with the core purpose and prerequisite steps, and every sentence earns its place by conveying operational constraints, alternatives, or behavioral caveats without 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?
With no output schema, the description compensates by explaining exactly what to expect on return (still publishing, null permalink), how to obtain final status via get_post, and how wait works. It also covers edge cases like threadItems failure behavior, YouTube scheduling, and unsupported scheduling elsewhere, making it complete for this complex 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?
Even though schema description coverage is 100%, the description adds crucial meaning not fully captured in the schema: per-channel character limits (Threads 500, YouTube 5000 UTF-8 bytes), YouTube requiring exactly one video and a title, mediaIds provenance and the three ways to get one, and the exclusivity of content vs threadItems. This goes well beyond the schema's terse field 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 opens with the specific verb 'Post' and resource 'social channels', immediately establishing the tool's function. It clearly distinguishes itself from siblings like reply and media tools by explicitly mentioning 'instead of publish-then-reply' and describing the media acquisition pipeline.
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 gives explicit when-to-use and how-to-use guidance: get accountIds from select_channels, never guess the channel, choose media ids based on file location via media_from_url/media_upload_link/media_presign+media_complete, and use threadItems for long posts instead of publish-then-reply. It also explains when to pass wait:true and how to check final status with get_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
replyReply to a postAReply to a post or to a reply. Leave replyTo empty to reply to the post itself; pass a reply id from list_replies to nest a reply under that reply.Like publish, this returns before the reply is live. Call get_post with the returned id to see the final status and link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. | |
| content | Yes | ||
| replyTo | No | Reply id from list_replies. Omit to reply to the post itself. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations mark this as destructive (write operation), the description adds critical behavioral context: the reply is not immediately live and returns before completion, requiring a follow-up call to get_post. This goes beyond the annotation and informs the agent of async semantics.
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, no filler. Every sentence adds value: the first explains the core action and nesting option, the second explains async behavior and how to verify. Perfectly structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description covers the essential workflow: how to reply, how to nest, that it's asynchronous, and how to check the final result. It also references relevant siblings (list_replies, get_post, publish) for seamless integration.
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 description explains the relationship between id, content, and replyTo, especially the nesting logic for replyTo. Schema covers id and replyTo with descriptions, but content lacks description; however, the tool description does not repeat schema but adds usage context. Coverage is 67%, so it deserves a slightly above-baseline score.
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 'Reply to a post or to a reply' with a specific verb and resource, distinguishing it from sibling tools like publish and list_replies. It also explains nesting behavior, 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?
Explicitly explains when to use the replyTo parameter (empty for top-level reply, reply id from list_replies for nested replies) and directs the user to get_post to verify status. This provides clear 'when and how' guidance beyond the schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
retry_postRetry a failed postARetry the targets that failed on a publish. Targets that already went out are left alone, so this never double-posts. If nothing failed you get nothing_to_retry. Only applies to posts published through us.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | A publish id (post_…), a channel-side id, or a post link (https://www.threads.com/@handle/post/CODE). Links work for posts written in the channel's own app too, as long as the account is connected here. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare destructiveHint=true and readOnlyHint=false, so the agent knows it's a mutation. The description adds valuable behavioral details beyond that: 'Targets that already went out are left alone, so this never double-posts' and 'If nothing failed you get nothing_to_retry', which clarifies the mutation semantics and expected response.
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, front-loaded with the core purpose, then two sentences of constraints and behavior. Every sentence earns its place without redundancy or unnecessary detail.
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 tool with no output schema, the description provides sufficient context: purpose, constraints, and the 'nothing_to_retry' response. It lacks explicit details about the success return value or whether retries are asynchronous, but these are minor gaps given the tool's simplicity.
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 only one parameter ('id') and its description is already thorough, covering accepted formats (publish id, channel-side id, post link) and conditions. Since the schema description coverage is 100%, the tool description adds no further parameter semantics, so the baseline score of 3 applies.
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 with a specific verb ('Retry') and resource ('failed targets on a publish'). It distinguishes itself from sibling tools by noting it never double-posts and only applies to posts published through us, making its scope explicit.
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 clear context: use when a publish had failed targets. It states exclusions ('Only applies to posts published through us') and a key safety behavior ('never double-posts'). It doesn't explicitly name alternative tools, but the context is sufficient to differentiate from publish or delete_post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
select_channelsSelect channels to post toAPick which connected channels to post to. Call this before publish and show the result to the person. Leave scope empty to get the candidate list and let them choose. Use scope: "all" for every active channel, or an array mixing platform names ("threads"), handles ("@vibe.trender") and account ids. Duplicates are folded, expired and not-yet-live channels are dropped into skipped with a reason, a sentence you can read to the person, and a link to reconnect. Pass the returned accountIds to publish unchanged. limits is the tightest rule across the chosen channels, so write to that. If both accountIds and candidates come back empty, nothing is connected yet. Send the person to https://uplika.com/dashboard/connections to connect a channel, then call this again.
| Name | Required | Description | Default |
|---|---|---|---|
| scope | No | Omit to list candidates, "all" for every active channel, or an array of platform names, handles or account ids. | |
| workspaceId | No | Which workspace this is for. Only needed when the account has more than one — the error tells you the ids when it matters. Leave it out if it is already decided; do not ask the person again. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavior beyond the readOnlyHint annotation: duplicate folding, dropping expired/not-yet-live channels into `skipped` with a reason and link, the meaning of `limits`, and the instruction to pass `accountIds` to publish unchanged. It also clarifies the empty-candidates edge case. This fully discloses the tool's runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries essential guidance. It is front-loaded with the most important instruction ('Call this before publish') and then logically proceeds through scope options, result handling, and fallback. No word is wasted; the length is justified by the tool's complexity.
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 fully explains what the tool returns: candidates, skipped list, limits, accountIds, and the empty case. It also provides connection-recovery guidance. This is complete for a selection tool in this context, covering all observable outcomes and the publish linkage.
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?
While the schema already describes both parameters (100% coverage), the description greatly enriches their semantics: scope's omit-vs-all-vs-array behavior, workspaceId's optionality and error-driven prompting, and the relationship of the returned `accountIds` to publish. This goes well beyond the schema's basic 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 opens with 'Pick which connected channels to post to,' which is a specific verb and resource. It clearly distinguishes from sibling tools like publish, list_channels, and get_quota by framing this as the channel-selection step before publishing.
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?
Explicitly instructs 'Call this before publish and show the result to the person.' It also explains when to omit scope (candidate list), when to use "all", and how to handle mixed arrays. The fallback guidance for empty results (send to connection dashboard) provides clear when-to-use context and a next step.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user or an account that owns the GitHub organization, then choose Claim with GitHub.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
