I do everything related to Twitter posting and campaigns
Scored across 10 tools
Each tool targets a distinct action (follow, like, retweet, DM, search, mentions, thread retrieval), so an agent can usually pick correctly. The only real overlap is post_tweet vs post_twitter_thread, which descriptions disambiguate reasonably well, and converse is a clear meta/fallback tool.
All names use snake_case and virtually all follow a verb_noun pattern (follow_user, get_mentions, like_tweet, send_dm). Two minor deviations — the bare verbs 'converse' and 'retweet' — break the pattern slightly but remain readable and unambiguous.
Ten tools is a well-scoped surface for a Twitter agent, covering the main engagement and posting actions without padding. Each tool maps to a real operation an agent would need.
Core posting, engagement, and read operations are present, but there are notable gaps: no user profile lookup, no fetching a user's timeline, and no undo operations (unlike, unfollow, delete tweet). These omissions will force agents into dead ends for common requests like 'what did this person tweet' or 'undo that like'.
Reply conversationally when the request is ambiguous or needs clarification.
| Name | Required | Description | Default |
|---|---|---|---|
| reply_hint | No | Optional hint for the conversational reply. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It says nothing about whether this ends the turn, whether it mutates state, whether it should be combined with other tool calls, or what the reply consists of — significant gaps for a tool with zero structured behavioral coverage.
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 tight sentence that front-loads the action and appends the trigger condition; nothing is wasted. It is efficient, though it is efficient at a fairly low level of 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?
The tool is low-complexity (one optional param, no output schema), so the short description is defensible, but with no annotations and no output schema the description should at least clarify the conversational fallback's role in the turn lifecycle. It stops just short of that.
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?
There is one optional parameter (reply_hint) whose schema description already covers it at 100% coverage, so the baseline of 3 applies. The description adds no syntax, format, or influence guidance beyond what the schema already supplies.
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?
It gives a verb ('reply conversationally') and a trigger condition ('when the request is ambiguous or needs clarification'), which separates it from the calendar siblings by function. However, the 'resource' is nebulous — there is no statement of what the reply acts on or produces, so the agent must infer it is a non-action fallback.
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 names one condition for use: ambiguity or need for clarification. It implies, but never states, that the event-management siblings (add/update/delete/check events) are the alternative when the request is clear, leaving the when-not boundary to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: follow user
| Name | Required | Description | Default |
|---|---|---|---|
| usernames | No | Handles to follow (without @) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only restates the tool name and does not describe side effects, rate limits, authentication requirements, idempotency, or what happens on failure.
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 extremely short and front-loaded, with no wasted words. It reads as a fragment rather than a complete sentence, but it is appropriately sized for a simple one-parameter 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?
Given the lack of annotations and the mutation implied by "follow," the description should disclose behavioral context such as permissions or side effects. The schema handles the only parameter, but the description leaves significant behavioral gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage and documents the single `usernames` parameter, including the "without @" note. The description adds no meaning beyond the schema, so the baseline 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 states a specific verb and resource ("follow user") and names the platform ("X / Twitter"), making it distinguishable from sibling actions like like_tweet or retweet. It does not explicitly differentiate itself from alternatives, but the action is clear.
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 alternatives, no prerequisites such as authentication, and no exclusions or edge cases. Usage is only implied by the verb.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: get mentions
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | How many mentions (1-50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure, yet it says nothing about ordering (recency vs relevance), pagination, authentication requirements, or rate limits. Only the weak implication of 'get' that this is a read operation is conveyed. This is a significant gap for a network-backed retrieval 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?
The description is a single short label with zero waste, but it also earns little; brevity here reflects under-specification rather than disciplined front-loading. It is appropriately sized only in the sense that there is almost no content to organize.
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 annotations, no output schema, and no parameter guidance in the description, an agent cannot know what the response looks like, whether mentions are of the authenticated account, or how results are ordered. For a simple one-parameter tool this is still notably incomplete.
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%, and the single parameter ('count', 1-50) is fully documented in the schema. The description adds nothing beyond the schema, but with full coverage the baseline of 3 applies. It does not clarify default count or what happens when count is omitted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb and resource ('get mentions') and prefixes the platform ('X / Twitter'), so the resource is identifiable. But it is essentially a restatement of the tool name with no additional specificity about whose mentions or what subset is returned. No sibling deals with mentions, so distinguishing from siblings is not a major need, keeping this at a minimum-viable 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_tweets or get_thread, nor any stated prerequisites (e.g. authenticated user context). The only implied usage comes from the name itself. This matches the 'no guidance' level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: get thread
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | No | ||
| tweet_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With zero annotations, the description carries the full behavioral burden and delivers nothing: no indication of auth requirements, rate limits, whether replies from other users are included, result ordering, or truncation behavior. Nothing beyond the tool name is disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
It is short, but the extreme brevity is under-specification rather than efficiency; the entire content is a platform tag plus a restatement of the name. No information is front-loaded because there is no 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?
A two-parameter tool with no annotations and no output schema needs the description to explain return shape and parameter selection, and this one explains neither. An agent cannot call it confidently, especially regarding which identifier to pass.
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% for two parameters, and the description offers no help at all. Critically, it never explains the relationship between tweet_id and tweet_url — whether they are alternatives, whether one is preferred, or what happens when both or neither is supplied (both are optional).
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 adds only a platform prefix ("X / Twitter") to the tool name, effectively restating "get thread." It doesn't say whether it returns the root tweet, all replies, or the author's self-thread, and gives no hint of how it differs from search_tweets or get_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?
No when-to-use guidance and no named alternatives, despite several plausible siblings (search_tweets, get_mentions). The only implied usage is the bare notion of retrieving a thread, with no exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: like tweet
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | No | ||
| tweet_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden, and it discloses almost nothing: no auth requirements, no rate-limit behavior, no statement of what happens if the tweet is already liked (idempotency), and no error conditions. Only the implicit mutating nature of 'like' is conveyed.
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?
It is short, but the brevity reflects under-specification rather than efficient front-loading; there is no wasted sentence because there is effectively only a fragment. It does not earn its place as a usable definition.
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 annotations, no output schema, and two undocumented optional identifier parameters, the description leaves the agent unable to determine how to construct a valid call. A mutation tool with this little context needs substantially more disclosure.
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 both parameters are optional, yet the description says nothing about tweet_id versus tweet_url — no indication of whether they are mutually exclusive, which takes precedence, or what format either requires. This is the exact gap the description should have filled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a verb (like) and a resource (tweet) plus the platform, so the basic action is inferable. But it is essentially a restatement of the tool name with no differentiation from siblings like retweet or post_tweet, and no statement of scope or effect.
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 on when to use this instead of retweet or other engagement tools, and no preconditions such as needing an authenticated account or the tweet existing. The agent must infer everything from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: post tweet
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Tweet topic or angle | |
| schedule_hint | No | Optional timing hint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full disclosure burden and provides essentially none: it doesn't say the post is public and irreversible, whether an account/authentication is required, whether there are rate limits, or whether media or links are supported. Only the bare implication of 'post' signals a write operation.
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 five-word description is economical and front-loaded with no filler, but it is under-specified rather than genuinely concise. There is no wasted sentence, yet the single fragment carries almost no operative 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 mutation tool with no annotations, no output schema, and vaguely named parameters (notably schedule_hint, which hints at scheduling or content composition without explanation), the description leaves too much unanswered. Nothing tells the agent what the tool returns, which account it posts to, or how the topic parameter is turned into content.
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 'topic or angle' and 'Optional timing hint' are already documented in the schema itself. The description adds nothing beyond that, which lands at the baseline of 3 rather than being penalized for a coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description pairs a specific verb (post) with a specific resource (tweet) and prefixes the platform ('X / Twitter'), so the agent knows the action is publishing a tweet. It stops short of distinguishing this from the sibling post_twitter_thread, which is a realistic confusion given the near-identical vocabulary; the word 'tweet' (singular) only implicitly signals a single 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?
There is no statement of when to use this versus post_twitter_thread, retweet, or send_dm, nor any exclusions. With zero required parameters, an agent also gets no instruction about whether it may invoke the tool with no arguments, which is a real risk left unaddressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: post twitter thread
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No | Thread topic | |
| tweet_count | No | Approximate number of tweets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for a mutation tool, yet it says nothing about authentication requirements, whether the thread posts immediately or is drafted, rate limits, partial-failure behavior, or what happens if tweet_count is exceeded or omitted.
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?
It is short, but the brevity comes from under-specification rather than efficiency. The 'X / Twitter:' prefix is redundant padding when the name already says twitter, and there is no front-loaded scoping 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 public-posting mutation with zero annotations and no output schema, the definition should say what gets created and what is returned; instead it provides only the platform name. An agent cannot verify success semantics or side effects from this 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?
Schema description coverage is 100%, so both parameters (topic, tweet_count) are already documented in the schema. The description neither adds syntax, constraints, nor defaults beyond the schema, so the baseline 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 is essentially the tool name respelled: 'post twitter thread' adds no verb nuance, scope, or resource detail beyond 'post_twitter_thread'. It does imply publishing a multi-tweet thread as opposed to a single tweet, but this distinction comes entirely from the name, not from the description.
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 on when to use this instead of the sibling post_tweet, nor on the relationship to get_thread (which reads a thread). The agent must infer that this tool publishes while get_thread retrieves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: retweet
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_id | No | ||
| tweet_url | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and discloses nothing: not whether retweeting an already-retweeted tweet errors or is a no-op, not whether the action is reversible (unretweet), and not whether auth is required.
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?
Brevity here is under-specification rather than economy; the single fragment earns its place only as a platform label and leaves the tool effectively undocumented.
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 zero annotations, no output schema, and two undocumented parameters, the definition supplies none of the information an agent needs to invoke this mutation correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no parameter meaning at all. It never clarifies whether tweet_id and tweet_url are alternatives, whether either is required (required list is empty), or what format tweet_url takes.
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?
"X / Twitter: retweet" restates the tool name with a platform prefix and adds no scope or distinguishing detail. An agent cannot tell from this how it differs from siblings like like_tweet or post_tweet beyond the obvious verb.
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 contains no guidance on when to use this tool, when not to, or which sibling to prefer. Nothing indicates prerequisites such as authentication or an existing tweet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: search tweets
| Name | Required | Description | Default |
|---|---|---|---|
| count | No | Max results (1-20) | |
| query | No | X search query |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses nothing: no auth requirements, rate limits, result ordering, pagination, or empty-result behavior. "Search tweets" conveys no behavioral facts an agent could act on.
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 words with zero padding and the platform qualifier front-loaded, which is optimally compact. However, the brevity reflects under-specification rather than disciplined editing, keeping it short of a 5.
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 annotations and no output schema, the description should at least indicate what is returned, what the default `count` is, and whether `query` is optional. None of these are covered, leaving an agent to infer everything from the schema alone.
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 both `query` and `count` are already documented in the schema, and the baseline of 3 applies. The description mentions neither parameter and adds nothing (e.g., no query-syntax 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?
"X / Twitter: search tweets" expands the tool name into a platform-scoped statement but adds no distinguishing verb or resource detail beyond it. An agent cannot tell how this differs in scope from get_mentions or get_thread, which also retrieve tweets.
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, when-not-to-use, or alternative-routing guidance is offered. The siblings include get_mentions and get_thread, which overlap heavily with a tweet search, yet neither is referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
X / Twitter: send dm
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | DM body | |
| username | No | Recipient handle without @ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. Sending a DM is an irreversible outbound side effect, yet the description says nothing about permissions/authentication, rate limits, whether the message is delivered to a stranger, editability or failure modes. This is a significant gap for a mutation 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?
It is front-loaded and wastes no words, but it is a bare fragment rather than a sentence, and the brevity comes at the cost of information rather than through efficient editing. Short is good here, yet too little is said.
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 annotations and no output schema, the description should explain the side effect and expected result, but it says nothing about what happens on success or failure. For a two-parameter messaging action the description is under-specified relative to the risk it represents.
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% and both parameters (message body, recipient handle without @) are documented in the schema, so the baseline applies. The description adds no syntax, length, or formatting details beyond what the schema already states.
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 text 'X / Twitter: send dm' restates the tool name and adds only the platform qualifier; it names a verb and resource but gives no scope detail (single recipient? plain text? rate limits?). It does implicitly separate this from siblings like post_tweet, but only because the name does the work, not the description.
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 when-to-use guidance and no exclusions. Notably, sibling 'converse' could plausibly also target a user privately, and the description does nothing to route between them or state any precondition (e.g., must follow the user, recipient must accept DMs).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
debug_update_existing_codefollow_usergenerate_and_execute_codegenerate_code_onlyget_mentionsget_threadlike_tweetpost_tweetpost_twitter_threadretweetsearch_tweetssend_dmconversedebug_update_existing_codegenerate_and_execute_codegenerate_code_onlytwitter__conversetwitter__debug_update_existing_codetwitter__generate_and_execute_codetwitter__generate_code_onlytwitter__conversetwitter__debug_update_existing_codetwitter__generate_and_execute_codetwitter__generate_code_onlyPost to social media (Facebook, Instagram, LinkedIn, Pinterest, YouTube, TikTok, X/Twitter and more)
I do everything related to Google Blogger content
X/Twitter search, posts, comments, user profiles, user posts/replies and video transcripts.
Schedule social posts to TikTok, Instagram, Facebook, YouTube and X; manage accounts and media
Add one secure layer between your agents and this server.
