threads_profile_posts_listList posts from a Threads profile by handle. Returns a list (use cursor when paginated).
| Name | Required | Description | Default |
|---|---|---|---|
| trim | No | When true, returns a smaller response with fewer post fields when available. | |
| handle | Yes | Threads handle whose posts should be listed. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint=true and openWorldHint=true, so the description is not burdened for safety disclosure. It adds value by specifying the return type ('Returns a list') and pagination behavior ('use cursor when paginated'), which are not present in the annotations or schema. This helps the agent understand what to expect without over-explaining.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical note, delivering the core action and a key behavioral detail without extra fluff. The essential 'List posts by handle' and pagination hint are front-loaded, making it easy for an agent to parse quickly. 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 list tool with an output schema absent, the description covers the essential return type and pagination. It doesn't explain the exact structure of the list items, but the tool's straightforward nature and the presence of the schema for parameters make this acceptable. The missing explicit mention of the 'trim' parameter is a minor gap, but the schema covers it, so completeness is adequate.
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%—both parameters have descriptions ('Threads handle whose posts should be listed' and 'When true, returns a smaller response...'). The description text adds no additional parameter-level meaning beyond the schema, and it does not mention the 'trim' parameter at all. It stays at the baseline because the schema already does the heavy lifting.
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 'List posts from a Threads profile by handle', which is a specific verb-resource pair with the key input (handle) and the resource type (posts). It clearly distinguishes itself from siblings like threads_post_get (single post) and threads_profile_get (profile info) without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that there are other profile post list tools for different platforms (e.g., bluesky_profile_posts_list) nor does it state when one might prefer this over threads_search_list. There is no 'when not to use' or exclusion criteria, leaving the agent to infer from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool is clearly scoped to a specific platform and action (e.g., facebook_post_get vs instagram_post_get). Descriptions explicitly differentiate similar tools across platforms, and within-a-platform tools like tiktok_search_videos_list vs tiktok_search_hashtag_list have clear disambiguation notes.
All 167 tools follow a strict `platform_resource_action` pattern (e.g., youtube_video_comments_list). No mixing of styles—snake_case throughout, with consistent verb ordering (get, list, search, etc.).
The server has 167 tools, which is far beyond the typical well-scoped range of 3-15. While the broad multi-platform scope justifies many tools, this extreme number makes the tool surface overwhelming and difficult for an agent to navigate efficiently.
The tool set covers a wide range of platforms and operations including profile retrieval, post/video fetching, comments, search, transcripts, and ad library access. Minor gaps exist (e.g., no Facebook events or LinkedIn messaging), but the surface is comprehensive for a read-only data aggregation use case.