meta-threads-mcp

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool targets a distinct resource and action; even the three creation variants are clearly separated by media type. The only subtle overlap is between get_replies and get_conversation, but their descriptions differentiate direct replies from a full threaded view.
Naming Consistency5/5
All tools follow a consistent pattern: prefixed with `threads_` followed by a verb and noun (e.g., create_post, get_replies, hide_reply). No mixed naming conventions, making the set predictable.
Tool Count5/5
15 tools is appropriately scoped for a social media API server, covering content creation, retrieval, deletion, replies, moderation, and analytics without feeling bloated.
Completeness4/5
Core content lifecycle (create/get/delete/reply) is covered along with moderation (hide/unhide) and analytics for both media and user. Some gaps exist such as searching posts or accessing other users' profiles, but these are beyond the typical API scope, so overall this is a solid surface.
Average 3.5/5 across 15 of 15 tools scored. Lowest: 2.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on January 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only restates the tool's purpose, providing no information about irreversibility, permissions, or 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core description is short and front-loaded, but includes an 'Args' section with 'ctx: FastMCP request context' which is not part of the user-facing input schema, adding unnecessary noise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a delete operation, this description is incomplete. It omits whether deletion is permanent, whether it returns a value, or any failure conditions. The large sibling set and output schema suggest more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description only says 'post_id: The ID of the post to delete', which is redundant with the parameter name. It does not specify ID format or any other meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Delete a Threads post' with a specific verb and resource. It is the only deletion tool among siblings, distinguishing it from create/get/reply operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, no prerequisites, ownership restrictions, or consequences are mentioned. It simply says what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Get', which implies a read operation, but does not mention permissions, ownership requirements, rate limits, or what happens if the media_id is invalid. This minimal transparency is insufficient given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loads the purpose. However, it includes a 'ctx' parameter in the Args section that is not present in the input schema, which could mislead the agent. This minor structural flaw prevents a perfect score, but overall it is compact and well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (single parameter, output schema present), the description is minimally adequate. It states the core purpose and identifies the required parameter. However, it lacks usage guidelines, behavioral context, and parameter semantics beyond the schema, leaving some gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. However, it only states 'The ID of the media/post to get insights for', which essentially restates the parameter name and adds no new semantics (e.g., format, required vs optional, or validation). The parameter name 'media_id' is already self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves metrics/insights for a specific post, using the specific verb 'Get' and identifying the resource ('a specific post'). This distinguishes it from sibling tools like threads_get_user_insights (user-level) and threads_get_post (post details).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. It simply states what the tool does without contextualizing when it should be selected over threads_get_user_insights or other post-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description does not mention authentication requirements, error behavior (e.g., post not found), or whether hidden/private posts are excluded. It essentially restates the tool name without adding meaningful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the main purpose. The Args block is efficient, though including 'ctx: FastMCP request context' is unnecessary since ctx is not in the schema and adds minor noise. Overall, it is compact and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-post retrieval tool with an output schema, the description is adequate but not rich. It lacks guidance on when to use it relative to siblings and does not disclose behavioral details like permissions or error cases. The output schema covers return values, but the missing usage context keeps this from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage for post_id, and the description compensates minimally by stating 'post_id: The ID of the post to retrieve.' This adds a human-readable explanation beyond the raw schema, but it is terse and does not provide format, examples, or additional constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get a Threads post by ID,' which specifies a clear verb ('Get'), a resource ('Threads post'), and a scope (by ID). This distinguishes it from sibling tools like threads_get_user_posts, which retrieves multiple posts for a user, and threads_get_replies, which gets replies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. It does not mention conditions such as 'use when you have a post ID' or exclude cases like getting a user's posts, so there is no direct comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden of behavioral disclosure. While 'get' implies a read operation, the description does not mention pagination, authentication, rate limits, or response behavior, leaving important operational traits undisclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, with a clear one-line purpose followed by a compact argument listing. There is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and has an output schema, so return details are covered elsewhere. However, the description lacks alternative-tool guidance and behavioral detail, making it only minimally complete for an agent to select it confidently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema itself provides no descriptions, the description clarifies the single parameter: 'post_id: The ID of the post to get replies for.' This adds meaningful semantics beyond the raw schema and fully compensates for the 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb + resource: 'Get replies to a Threads post.' It clearly states the tool's function, but it does not explicitly differentiate itself from the sibling tool threads_get_conversation, which may overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as threads_get_conversation or threads_get_post. There are no exclusions, prerequisites, or context cues beyond the basic description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 merely restates the action without mentioning reversibility, permissions, side effects, or what happens to the reply after hiding. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by args. However, it includes 'ctx: FastMCP request context' which is not part of the input schema and may confuse agents. Overall, it is appropriately sized with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool being simple, the description lacks usage guidance and behavioral transparency. It does not reference sibling tools like 'threads_unhide_reply' or explain the effect of hiding (e.g., visibility to others, reversibility). With output schema present, return values are not needed, but the missing context still makes the description incomplete for an agent to correctly select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the parameter. It provides a minimal explanation ('The ID of the reply to hide') that is essentially a restatement of the parameter name. It does not specify format, origin, or constraints, adding little value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb+resource construction, 'Hide a reply to your post,' which clearly distinguishes it from siblings like 'threads_unhide_reply' (the reverse action). The purpose is immediately unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives basic context ('to your post') that implies the tool applies to replies on your own posts, but it does not explicitly state when to use this tool over alternatives, nor does it mention exclusions or the existence of 'threads_unhide_reply' for reversing the action. Usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must shoulder the transparency burden. It adds the context of 'authenticated user' but does not disclose pagination behavior, rate limits, or return format. The inclusion of 'ctx' as an arg not in the schema could confuse an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but includes the 'ctx: FastMCP request context' line, which is not part of the user-facing schema and adds noise. The purpose sentence is front-loaded, but the Args block is not.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema, so the description needn't detail return values. However, it lacks information about auth requirements beyond 'authenticated user' and doesn't mention pagination or filtering caveats. The ctx discrepancy also detracts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides zero description coverage for the limit parameter. The description compensates by explaining 'Maximum number of posts to return (default 10)', giving meaningful semantics beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the authenticated user's recent posts' – a specific verb and resource. This distinguishes it from siblings like threads_get_post (single post) and threads_get_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like threads_get_replies or threads_get_conversation. No exclusions or selection criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says 'Get' implying a read operation, but does not disclose specifics such as whether the full thread includes the original post, any limits on thread depth, or pagination behavior. This is insufficient given the lack of annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one purpose sentence plus an Args list. It is front-loaded with the main purpose. The Args list is somewhat redundant with the schema but does add meaning. Overall, it is tightly written without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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, output schema exists), the description is not entirely inadequate. However, it lacks important context such as whether the full thread includes nested replies, any rate-limit considerations, or a note on how this differs from getting direct replies. It meets only the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. The Args section explains 'post_id: The ID of the post to get the conversation for,' adding meaningful semantic context beyond the bare schema type. It also mentions the ctx context parameter, which helps clarify the invocation signature, though ctx is not part of the user-supplied parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the full conversation thread for a post,' which is a specific verb-resource pair. It distinguishes this from sibling tools like threads_get_post (single post) and threads_get_replies (direct replies) by emphasizing 'full conversation thread.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like threads_get_replies. It does not mention exclusions or preference contexts, leaving the agent to infer usage from the name. This is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It only states the action without disclosing authentication requirements, side effects, or error behavior. For a tool that depends on the authenticated user, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The main sentence is front-loaded and clear, but the 'Args: ctx: FastMCP request context' line is unnecessary and not part of the actual input schema. It adds noise and slightly undermines the conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has an output schema, and no parameters, so the description is mostly adequate. However, it omits any mention of authentication requirements or how the profile is scoped, which could be important for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty, so there is nothing to explain. The description mentions 'ctx: FastMCP request context' but that is an implementation detail not reflected in the schema. With 0 params, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the authenticated user's profile,' which is a specific verb+resource. It uniquely identifies the tool among siblings, none of which are about profiles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor does it mention exclusions. While it is obviously the tool for profiles, the lack of explicit context around authentication or use cases leaves the agent without clear direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 states that it creates and publishes a post, but does not mention authentication requirements, rate limits, what happens on failure, or whether the image is fetched from the URL server-side. It also doesn't describe the response structure beyond relying on the output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with a clear first sentence and a compact Args list. It includes the internal 'ctx' parameter, which is not part of the user-facing schema, adding a small noise. Overall, it is well-structured and front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are presumably covered elsewhere. However, for a mutation tool with no annotations, the description lacks essential context such as authentication, whether the post publishes immediately, and any constraints on the image URL. It is minimally viable but leaves gaps in operational understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero descriptions for image_url and text, and only a minimal description for reply_control via the $defs. The description compensates by listing each parameter with brief semantics: 'URL of the image to post', 'Optional text content', 'Who can reply - ...'. While not deeply detailed, it adds meaningful context beyond the schema's bare field names and enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create and publish a post with an image to Threads', which is a specific verb+resource+scope. It clearly distinguishes from sibling tools like threads_create_post and threads_create_video_post by focusing on image posts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for image posts via the tool name and the image_url parameter, but it does not explicitly compare with alternatives or state when to use this tool over others. For example, it doesn't say 'use this for images, use threads_create_post for text-only posts.' Thus, usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It only states the action ('create and publish') without covering potential side effects, authorization requirements, rate limits, or the nature of the returned result. The inclusion of 'ctx' as a parameter is also not part of the actual schema, adding minor confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with one main sentence and a short argument list. However, the 'Args' block largely duplicates schema information and could be trimmed, but it does not harm usability significantly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values do not need explanation. However, the description lacks usage guidance and behavioral transparency, though the parameter explanations are sufficient for basic invocation. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, and the description compensates by explaining each parameter: video_url as the URL, text as optional content, and reply_control with its enum values. This adds needed meaning beyond the bare schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: 'Create and publish a post with a video to Threads.' It clearly distinguishes from sibling tools like threads_create_post and threads_create_image_post by specifying the video medium.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for video posts but does not explicitly compare to alternatives or state when not to use this tool. It provides the required video_url parameter but lacks exclusions or explicit guidance versus sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
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 discloses that the operation is read-only and scoped to the authenticated user, but it does not reveal what metrics are included, whether pagination or date ranges apply, or any rate-limit or authentication nuances.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The core sentence is concise and front-loaded. However, the 'Args: ctx: FastMCP request context' line is boilerplate that adds no value, preventing a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a zero-parameter read tool with an output schema, the description is sufficiently complete. It names the resource and scope, and the output schema can handle return-value details. It could add context on what 'insights' includes, but the low complexity keeps this adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 per the rubric. The description adds the contextual point that insights are for the authenticated user, which is meaningful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves user-level metrics/insights for the authenticated user, using a specific verb and resource. The phrase 'user-level' distinguishes it from sibling tools like threads_get_media_insights (media-specific) and threads_get_user_posts (posts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys context ('user-level', 'authenticated user') but does not explicitly state when to use this tool versus alternatives or mention exclusions. Usage is implied rather than explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention authentication requirements, permission scopes, whether the reply is immediately visible, behavior on non-existent post_id, or any rate limits. The only behavioral hint is 'existing' post, which is minimal 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four lines total, with a one-line purpose followed by a compact args list. Every sentence provides value; there is no filler or repetition. It is front-loaded with the core action and precise parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 2-parameter tool with an output schema, the description covers the essential action and parameters. However, it omits any behavioral context (e.g., auth, visibility, error handling) that would make it fully self-contained. The existence of an output schema partially compensates for not explaining return values, but the description remains minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clearly explains both parameters: post_id as 'The ID of the post to reply to' and text as 'The text content of the reply', adding meaning beyond the bare schema types. It also documents ctx, which is not in the schema, aiding the agent in understanding the full invocation context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reply to an existing Threads post,' which uses a specific verb ('Reply') and resource ('existing Threads post'), clearly distinguishing it from sibling tools like threads_create_post or threads_get_replies. The word 'existing' also differentiates it from creating a new top-level post.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: it is for replying to an already-created post, not for creating a new post. However, it does not explicitly state when to use this tool over alternatives, such as threads_create_post for new threads or threads_get_replies for reading replies, nor does it provide exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the core state change (hidden -> unhidden), but omits side effects, prerequisites (e.g., reply must currently be hidden), permission requirements, or error behavior. This is minimal but acceptable for a simple state-transition tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two effective sentences plus a one-line argument spec. It is front-loaded with the action and contains no filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter state-change tool with an output schema, the description covers purpose and parameter adequately. It could add a pointer to threads_hide_reply as the counterpart, but the low complexity means this is a minor gap rather than a serious deficiency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; the description compensates by explicitly defining 'reply_id: The ID of the reply to unhide.' This is the only meaningful parameter, so semantics are clear. The mention of 'ctx' adds framework context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Unhide a previously hidden reply,' a specific verb ('unhide') and resource ('reply'), and unambiguously distinguishes it from the sibling 'threads_hide_reply' as its inverse. The purpose is immediately clear and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance or alternative names are provided. The intended use is implied by the verb 'unhide' and the phrase 'previously hidden,' but the description does not state when to choose this over other reply tools or mention its hide counterpart.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full responsibility. It discloses that the tool creates and publishes a post, but does not mention authentication requirements, failure conditions, or the public visibility of the post. These are relevant behavioral aspects 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and lists parameters compactly. The inclusion of 'ctx: FastMCP request context' is unnecessary for an agent but does not significantly hurt the overall clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers its core purpose and parameters. However, it omits prerequisites like authentication or account linking, and does not mention error handling. The presence of an output schema reduces the need to explain return values, but the description could still be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Even though schema description coverage is 0%, the description fully explains both parameters: text is defined as 'text content of the post' and reply_control lists all allowed values (EVERYONE, ACCOUNTS_YOU_FOLLOW, MENTIONED_ONLY). This provides complete semantic clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Create and publish a text post to Threads' with a specific verb, resource, and medium, clearly distinguishing it from sibling tools that create image or video posts. This gives an unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly identifies this tool as for text posts, and sibling names make alternative purposes apparent. However, it does not explicitly state when not to use this tool or provide direct comparisons with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses concrete behavioral information—the quota limits for posts and replies—which is essential for the user. It does not mention authorization or side effects, but for a simple read-only check these are less critical, and the output schema is present to document return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two lines—and front-loads the core purpose and quota numbers. The 'Args' line is minor boilerplate but does not detract from the clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with an output schema that likely explains return values, so the description only needs to convey the operation and key limits, which it does. The complexity is low, and the description covers all necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so the baseline score is 4 per the rubric. The description mentions 'ctx' as a FastMCP request context, which is a framework detail and not a user-facing parameter, so it does not meaningfully affect parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Check remaining publishing quota' with specific daily limits (250 posts/day, 1000 replies/day). The verb 'check' and resource 'publishing quota' precisely identify the tool's function, and no sibling tool mentions quota, so it is well-distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is for checking publishing quota, and there are no sibling tools with similar functionality to confuse it with. It doesn't explicitly state 'use before creating a post' or when not to use it, but the purpose is unambiguous and no alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![meta-threads-mcp MCP server](https://glama.ai/mcp/servers/MetaThreads/meta-threads-mcp/badges/card.svg)](https://glama.ai/mcp/servers/MetaThreads/meta-threads-mcp)

Score Badge

Copy to your README.md:

[![meta-threads-mcp MCP server](https://glama.ai/mcp/servers/MetaThreads/meta-threads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/MetaThreads/meta-threads-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/MetaThreads/meta-threads-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server