Enterprise Threads MCP Server

Server Quality Checklist

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

Latest release: v5.1.0
Disambiguation2/5
Many tools have overlapping purposes, especially in analytics (get_my_insights, get_enhanced_insights, get_engagement_trends, get_content_performance_report) and search (search_posts, search_by_hashtags, search_by_topics, search_mentions). While each tool has slight differences, the boundaries are unclear, causing potential misselection.
Naming Consistency2/5
Naming is inconsistent: some tools follow verb_noun (get_my_profile, create_reply), but others are noun phrases (auto_hashtag_suggestions, content_optimization_analysis, bulk_post_management) or use different verb prefixes. There is also mixing of 'thread' and 'post' terminology across similar actions.
Tool Count2/5
With 44 tools, the set is considerably over-sized for a social media server. Many tools could be consolidated (e.g., analytics tools, search variants), making the surface area unnecessarily complex and difficult to navigate.
Completeness4/5
The tool set is comprehensive, covering posting, engagement, search, analytics, user management, and setup. Minor gaps include lack of an edit/update post function and no direct single-post retrieval by ID, but these can be worked around via delete/repost and search.
Average 3/5 across 44 of 44 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 2 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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 provided, the description carries the full burden of behavioral disclosure, but it only says 'manage' without indicating side effects, permissions, or whether operations are destructive (e.g., archive_low_performers). It fails to disclose any concrete behavioral traits, leaving the agent in the dark about the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, so it is not verbose, but it is severely under-specified for a tool with nested objects and multiple actions. It sacrifices necessary detail for brevity, making it inadequate as a functional guide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (3 parameters, nested structures, no annotations, no output schema), the description is glaringly incomplete. It lacks any explanation of return values, side effects, or behavior, making it insufficient 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.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds zero parameter semantics. Schema coverage is low (33%), with many fields lacking descriptions, and the description does not compensate by explaining filters, bulk_operations, or the action enum. The agent cannot infer parameter meaning from this description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Manage multiple posts with bulk operations and analytics' is vague and largely restates the tool name. It does not mention the specific actions (analyze_performance, bulk_edit, content_audit, export_data) defined in the schema, nor does it distinguish this tool from siblings like get_content_performance_report or analyze_best_posting_times.
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. It does not mention any context, prerequisites, or exclusions, leaving the agent without meaningful direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavioral traits. It fails to mention whether this is a read-only analysis, what side effects (if any) exist, required permissions, rate limits, or return format details. The sole behavioral implication is 'analysis', which is safe to assume but not explicitly disclosed.
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 a single, concise sentence that front-loads the purpose. However, the word 'Advanced' is vague and does not earn its place, and the lack of concrete details makes the conciseness feel like under-specification rather than efficient writing.
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?
This tool involves 4 parameters (including a nested target_audience object) and no output schema. The description only vaguely mentions 'optimization recommendations' without detailing the types of analysis (e.g., engagement, SEO) or the nature of the output. Given the richness of sibling analysis tools, this description is too sparse for an agent to fully understand the tool's scope and expected results.
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 schema provides descriptions for 3 of 4 top-level parameters (content, analysis_type, optimization_goals; target_audience has nested property descriptions but no top-level description). Since coverage is around 75%, the schema does most of the heavy lifting. The tool description adds no parameter-level context, so it does not compensate for the missing target_audience object description, but the schema is adequate for basic usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Advanced content analysis with optimization recommendations' indicates the tool performs content analysis and provides recommendation outputs, but it lacks a specific verb and clear resource scope. It does not differentiate from sibling tools like get_content_performance_report or get_enhanced_insights, making it harder for an agent to select it correctly.
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 analyze_best_posting_times or get_engagement_trends. There are no prerequisites, exclusions, or alternative tool mentions, leaving the agent to infer usage 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get analytics...' which essentially restates the tool's name; it does not disclose how data is returned, whether it is read-only, or any rate limits or permission requirements. The read-only nature is implied by 'get' but not explicitly stated.
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 a single short sentence, which is concise, but it lacks substantive content. It essentially restates the tool's name and provides no further clarification, so it does not fully earn its place.
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?
The tool has 4 parameters, no output schema, and no annotations. The description provides no context about available metrics, date handling, or return format, leaving the agent under-informed for a broad analytics tool.
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?
Schema description coverage is 100%, meaning all four parameters have descriptions. The tool description adds no additional parameter semantics beyond the schema, 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.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get analytics and insights for your account' – a specific read operation with a clear resource (account analytics). However, it is vague and does not distinguish this from sibling tools like get_enhanced_insights, get_follower_growth_analytics, or get_content_performance_report, which also provide account-level analytics.
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. It does not mention any exclusions, prerequisites, or refer to sibling tools, leaving the agent to guess which analytics tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only restates the action ('Like a thread/post') without mentioning side effects, idempotency, permissions, or rate limits. This is a significant gap for a mutation-like action.
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 a single short sentence with no fluff, but it is under-specified, essentially restating the tool name without adding helpful context. It is not overly verbose, but it could be more descriptive.
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?
While the tool is simple with one parameter, the description lacks behavioral information and usage guidance. There is no output schema, no annotations, and no mention of return values or side effects, leaving the agent without enough context to use it correctly beyond the schema.
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 schema already documents post_id with a clear description, achieving 100% coverage. The description adds no additional 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Like' and identifies the resource as 'thread/post', clearly indicating the action. It is distinguishable from siblings like unlike_post or get_post_likes, though it does not explicitly differentiate them.
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. It does not mention that unlike_post is the reverse action, any prerequisites, or typical scenarios for liking a post.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description is a near-verbatim restatement of the tool name. It does not disclose side effects, permission requirements, or the impact on the original thread or the user's profile, providing no behavioral context beyond the verb.
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 a single short sentence with no wasted words, but it is so minimal that it fails to provide context, making it under-specified rather than effectively concise. It does not front-load any additional useful detail.
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 mutation tool with no output schema, the description should explain that a repost is created, its visibility, or how to undo it using unrepost_thread. It does none of this, leaving the agent to infer behavior and lacking completeness for even a simple tool.
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 schema already fully documents the single parameter post_id with its description 'ID of the post to repost', achieving 100% schema coverage. The description adds no parametric information, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'repost/share' with the resource 'another thread', clearly indicating the action. However, it does not explicitly distinguish this from similar tools like quote_post or publish_thread, so it lacks sibling differentiation.
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 repost_thread versus alternatives such as quote_post or publish_thread. There are no stated prerequisites, conditions, or exclusions, leaving the agent without context for tool selection.
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, the description carries the full burden for behavioral disclosure. It only says 'Setup' without indicating whether this is a write operation, whether it modifies external systems, requires authentication, or what side effects occur. This is a significant gap for a setup tool.
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 brief and front-loaded, but it is under-specified for the tool's complexity. It does not waste words, yet the single vague sentence lacks substance while not being overly verbose.
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?
Given the complex nested schema, multiple integration types, and no output schema or annotations, the description is far from complete. It provides no context on what the setup entails, return values, or expected behavior, making it inadequate for safe invocation.
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?
The schema has 33% description coverage, and the tool description adds no parameter information at all. It doesn't explain the meaning of integration_type or the nested objects, so the agent must rely solely on the incomplete schema descriptions.
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 clearly states the tool sets up Threads integration for websites/external platforms, using the verb 'Setup' with a specific resource. It distinguishes from sibling publishing/analysis tools, though 'Setup' is a bit generic and could be more explicit about creating a configuration.
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, prerequisites, or what scenarios it fits. It does not mention related tools like validate_setup, leaving the agent to infer usage from the name and schema.
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 bears the full burden of disclosing behavior. It only mentions that it is AI-powered and analyzes content, but does not state whether it is read-only, requires any authentication, or what side effects (if any) occur. It also doesn't mention how the user should provide media_url or how suggestions are returned.
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 a single concise sentence that gets to the point. It avoids unnecessary words, though 'AI-powered' is somewhat generic. Overall, it is well-structured and front-loaded.
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 simple purpose, the tool has a nested settings object offering multiple options, and no output schema is provided to clarify the response format. The description provides minimal context, leaving the agent uncertain about how to configure suggestions or interpret results. It is insufficient for a tool of this complexity.
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?
The input schema describes content and media_url adequately, and suggestion_settings has nested property descriptions. The description only reinforces the role of content analysis and adds no information about media_url or the configurable settings like count, style, or industry_focus. With 67% schema coverage, the description could compensate but does not.
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 clearly states that this tool generates AI-powered hashtag suggestions from content analysis. It uses the noun 'suggestions' and indicates the input is content. While it doesn't explicitly contrast with sibling tools like search_by_hashtags, the purpose is unambiguous.
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. There is no mention of situations where it should not be used or which sibling tool to prefer. For instance, search_by_hashtags is for searching existing posts, but the description doesn't clarify this distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for behavioral disclosure. 'Follow a user' gives no information about side effects, permission requirements, reversibility, rate limits, or behavior when the user is already followed. This is a severe gap for a mutation operation.
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 a single concise sentence with no redundant words. It is front-loaded and easy to parse, though it is minimal to the point of under-specification.
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?
The tool is a simple mutation with one parameter and no output schema, but the description fails to cover essential behavioral context such as authentication needs, side effects, or error conditions. Without annotations, this is insufficiently 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?
Schema coverage is 100% for the single parameter user_id, which is already described as 'User ID to follow'. The description adds no additional meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Follow a user' clearly states the action (follow) and the resource (a user). It is specific enough to distinguish from sibling tools like unfollow_user or block_user by the verb, though it does not explicitly elaborate on scope or contrasts.
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 usage guidance is provided beyond the bare action. There is no mention of when to use this tool versus alternatives, prerequisites, or edge cases such as already following the user or private accounts. The usage is only implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It does not indicate whether the operation is read-only, what data or return structure to expect, whether any side effects exist, or any limitations. The simple phrase 'comprehensive report' gives no insight into cost, permissions, or output format, leaving a significant transparency 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 a single short sentence with no redundant words. It is front-loaded and efficient, but the use of 'comprehensive' is somewhat generic and could be more specific. It earns points for brevity but is not fully informative.
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?
With no output schema and no annotations, the description must compensate by explaining what the report includes and how it behaves. It merely says 'comprehensive,' which is vague. Given the tool's apparent complexity (multiple optional parameters, likely aggregated data), the description is incomplete and leaves the agent unclear about return values, time periods, and report scope.
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?
All four parameters are documented in the schema with descriptions (coverage 100%), including enums for period and report_type, and descriptions for metrics and include_comparisons. The tool description itself adds no parameter context, but the baseline of 3 applies because the schema does the heavy lifting. No parameter is left unexplained.
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 'Comprehensive performance report across all content' clearly indicates the tool produces a performance report and specifies the scope ('across all content'), which distinguishes it from sibling tools like thread-specific insights. The verb is implicit in the tool name, but the resource and scope are clear. It lacks explicit mention of the reporting granularity or metrics, but remains understandable.
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 such as get_my_insights or get_engagement_trends. There are no stated use cases, exclusions, or comparisons to siblings. The appropriate context must be inferred solely from the tool name and generic wording.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral disclosure. It merely states the tool analyzes engagement patterns and does not mention any traits such as output format, aggregation behavior, data scope, or side effects. This is a significant gap for a tool in a crowded analytics space.
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 a single concise sentence with no wasted words. It is front-loaded with the verb and clearly states the tool's purpose. It is appropriately sized for a tool with a well-defined schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is vague and does not explain what 'trends over time' means in practice—whether it returns a time series, aggregates across posts, or how to interpret results. With no output schema and no annotations, the agent lacks enough context to understand the tool's full behavior or distinguish it from similar analytics tools in the large sibling group.
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 100% description coverage for its three parameters (metrics, timeframe, granularity), each with clear enum values and descriptions. The description adds no parameter-specific meaning beyond the schema, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Analyze engagement patterns and trends over time' clearly states a specific verb ('analyze') and resource ('engagement patterns and trends') with a temporal scope. However, it does not differentiate this tool from many sibling analytics tools such as get_enhanced_insights or get_content_performance_report, so it falls short of a 5.
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. It does not mention exclusions, prerequisites, or alternative tools, leaving the agent to infer usage solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/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 disclosing behavioral traits. It only states 'Create and publish a new thread,' which repeats the tool name and implies a write operation. No details about authentication, rate limits, media handling, publishing behavior, or side effects are given. This is insufficient 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 a single short sentence, 'Create and publish a new thread.' It is concise and front-loaded with the core action. However, it provides no additional guidance, so it is not optimally informative, but it is appropriately sized for a simple tool.
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?
Given the tool has 4 parameters (including an enum for media type), a clear write operation, and no output schema, the description is minimal. It does not explain important context such as whether publishing is immediate, how media_url interacts with media_type, or any constraints. The profile of this tool is comparable to mid/low examples where more detail is needed.
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 100% coverage, with each parameter already having a description (e.g., 'text' as 'The text content of the thread'). The tool description adds no additional parameter meaning beyond what is in the schema. Per the rubric, baseline 3 is appropriate when schema coverage is high and the description does not compensate further.
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 clearly states the tool's function: 'Create and publish a new thread.' It uses a specific verb ('Create and publish') and resource ('a new thread'). While it does not explicitly differentiate from sibling tools like 'create_thread_chain', it is unambiguous for a thread publishing action.
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 about when to use this tool versus siblings such as 'create_reply', 'schedule_post', or 'create_post_with_restrictions'. There is no mention of prerequisites, alternatives, or exclusions, leaving the agent to infer usage from the name and schema.
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 mentions 'advanced automation and optimal timing,' which is vague and doesn't explain side effects, required permissions, the effect of omitting schedule_time, or how recurring schedules behave. Highly insufficient for a scheduling tool.
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 a single sentence and not verbose, but it's under-specified. 'Advanced automation' and 'optimal timing' are filler phrases that don't communicate concrete facts. It's concise but not structured to highlight key operational details.
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?
Given the tool's complexity (nested automation_settings, 5 parameters, no output schema, no annotations), the description is far from complete. It doesn't explain the scheduling flow, required parameters beyond the schema, or how it relates to sibling tools like auto_hashtag_suggestions or publish_thread. An agent would struggle to understand the tool's full capabilities.
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?
Schema description coverage is 80%, which is high, so the baseline is 3. The description adds no parameter-specific meaning beyond the schema; 'advanced automation' vaguely hints at the automation_settings object but doesn't explain it. The schema itself does the heavy lifting.
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 clear verb ('Schedule') and resource ('posts'), and hints at automation and timing. However, 'advanced automation' and 'optimal timing' are vague, and it doesn't explicitly contrast with immediate publishing tools like publish_thread, leaving some ambiguity.
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 publish_thread or create_post_with_restrictions. There are no exclusions, prerequisites, or contextual hints beyond the word 'schedule,' so an agent has no direction for tool selection.
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 is minimal and does not explain output format, whether it returns recommendations or raw data, or how the analysis period affects results, leaving significant behavioral ambiguity.
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 a single sentence with no redundant words, making it concise and front-loaded. It is appropriately sized for the tool's simplicity, though it could be slightly more informative without losing economy.
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?
The tool has no output schema, and the description does not explain the return value or how recommendations are presented. It also doesn't clarify the role of optional parameters or provide examples. Given the many sibling analytics tools, this is insufficient context for an agent to reliably invoke the tool.
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?
Schema descriptions cover all three parameters (timezone, content_type, analysis_period) at 100% coverage. The description adds no additional parameter semantics, so the baseline of 3 is appropriate; the schema already provides the necessary parameter meaning.
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 clearly states the tool's function: analyzing optimal posting times based on engagement. It uses a specific verb ('analysis') and resource ('optimal posting times'), distinguishing it from other analytics tools like engagement trends or content performance, though it doesn't explicitly name alternatives.
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 usage guidance is provided. The description does not specify when to use this tool versus other analytics tools, nor does it mention any prerequisites or recommended contexts, leaving the agent without direction on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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. 'Block a user' does not state whether blocking is reciprocal, reversible, affects content visibility, or has any side effects. This is a significant transparency 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 a single, clear sentence with no filler or repetition. It is appropriately concise for the simplicity of the tool, though it could benefit from more detail without becoming verbose.
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?
The description is extremely minimal. With no annotations, no output schema, and only one parameter, it leaves out critical context such as the effects of blocking, reversibility, permissions, and response behavior. Inadequate for a mutation tool.
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 schema already documents the single parameter user_id as 'User ID to block', providing 100% coverage. The description adds no additional meaning beyond what the schema states, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'block' with the resource 'user', clearly identifying a distinct action not shared by any sibling tool. It is unambiguous and immediately understandable.
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 like unfollow_user or manage_reply. There is no mention of use cases, exclusions, or prerequisites.
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 mentions the 20-item limit and the September 2024 update, but does not disclose side effects (e.g., publishing to profile), required permissions, or error behavior. This is minimal coverage for a creation 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 a single, front-loaded sentence ('Create multi-media carousel posts with up to 20 items') that is immediately understandable. The parenthetical '(September 2024 update)' is somewhat extraneous but provides useful temporal context, so it earns its place.
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 tool with no annotations and no output schema, the description is too sparse. It does not explain the outcome (e.g., post ID returned), whether the post is published immediately or saved as a draft, or how carousel_settings affect the behavior. Sibling tools like schedule_post and create_post_with_restrictions suggest alternative workflows that are not addressed.
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 already provides descriptions for all parameters (75%+ coverage), so the baseline is 3. The description adds marginal value by highlighting the 20-item limit and the September 2024 update, which reinforces media_urls maxItems, but it does not clarify semantics beyond the schema.
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 clearly states the action ('Create multi-media carousel posts') and resource, and adds a key constraint ('up to 20 items'). However, it does not explicitly differentiate from other creation tools like create_post_with_restrictions or schedule_post, which also create posts.
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. The description does not mention prerequisites, such as whether media must be hosted elsewhere or whether the post publishes immediately. The presence of several sibling creation-related tools makes this lack of guidance a significant 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?
With no annotations, the description carries the full burden of behavioral disclosure. It merely says 'Create post' without explaining potential side effects, permission requirements, or how restrictions affect the posting flow. This lack of detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and key differentiator. Every word earns its place, with no unnecessary fluff.
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?
Given the tool has 8 parameters and no output schema, the description is too sparse. It fails to contextualize the relationship with sibling posting tools or clarify the implications of the restriction settings. The schema covers parameter details, but broader usage context is missing.
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 provides 100% coverage of parameter descriptions, including enums for media_type, reply_control, and audience_control. 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create post') and the distinctive feature ('advanced reply and audience restrictions'). It distinguishes the tool from simpler posting tools, but it doesn't explicitly name sibling alternatives like 'publish_thread' or 'create_thread_chain'.
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 publish_thread, create_thread_chain, or create_carousel_post. The description lacks context about the intended use case or exclusions.
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 'Reply to a specific thread/post' and does not explain whether this creates a new reply, whether it can be scheduled, how reply_control affects visibility, or what response the caller should expect. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, and the core action is front-loaded. However, it is so brief that it sacrifices valuable explanatory content that could be provided without bloating the description.
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?
With no annotations and no output schema, the description must compensate, but it does not. It lacks context about the reply creation process, constraints, media handling, or return values. Given the 5-parameter schema and many sibling tools, more detail is needed for the agent to invoke this correctly.
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?
Schema description coverage is 100%, so the schema already documents all five parameters, including enums for media_type and reply_control. The description adds no extra parameter context, but the baseline of 3 is appropriate because the structured data is complete.
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 clearly states the action ('Reply') and the resource ('a specific thread/post'), making the core purpose obvious. It is not distinguished from sibling tools like manage_reply or quote_post, but it is specific enough to convey the intended operation.
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 about when to use this tool versus alternatives. The description implies usage for replying to threads/posts but does not mention exclusions, prerequisites, or when manage_reply or quote_post would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 'Get detailed audience demographic analysis', with no mention of the read-only nature, response format, rate limits, or any special behavior. While 'get' implies reading, the lack of detail leaves the agent with little insight into runtime semantics.
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?
A single short sentence with no wasted words, front-loaded with the core action. It is easily parsed and appropriately concise, although it adds no structural hints about the schema. It avoids being overlong or vague to the point of uselessness.
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?
The tool has no output schema and no annotations, so the description should explain what the demographic analysis includes (e.g., breakdown percentages, time ranges) and any prerequisites. It does none of that, leaving the agent with only the parameter schema. This is insufficient for a tool of this perceived complexity.
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 fully describes both 'period' (with an enum) and 'breakdown_by' (with an enum for each item), giving the agent clear parameter meaning. The description adds no additional context or syntax 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and a specific resource 'audience demographic analysis', making it understandable. However, it does not explicitly distinguish from sibling analytics tools like get_enhanced_insights or get_my_insights, nor does it mention that it pertains to the authenticated user's audience. It is specific enough but lacks comparative framing.
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 the many other analytics tools in the sibling list. There are no usage conditions, alternatives, or exclusions, so the agent must infer the appropriate context from the name alone.
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 bears the full responsibility for disclosing behavioral traits. It simply lists the type of analytics returned and does not mention potential side effects, data aggregation behavior, permissions/rate limits, or output structure. The read-only nature is implicit but not explicitly stated, and no additional behavioral context is given.
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 a single sentence that is front-loaded with the verb and resource, and it contains no fluff. It is concise and easy to parse, though the brevity sacrifices valuable detail.
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 tool with six optional parameters and no output schema, the description is insufficiently complete. It does not explain the output format, how this tool differs from the many overlapping analytics siblings, or any context about when to invoke it. The one-line description leaves significant gaps for the agent to operate effectively.
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 covers 100% of parameters with individual descriptions, so the baseline is 3. The description echoes some metric names (views, clicks, shares, demographics) already listed in the schema's 'metrics' and 'breakdown' fields, but adds no new meaning or contextual guidance about parameter relationships or usage patterns.
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 clearly states the tool's purpose with a specific verb ('Get') and resource ('advanced analytics'), along with concrete examples of returned data (views, clicks, shares, demographics). It is clear enough but does not explicitly differentiate from sibling analytics tools like get_my_insights or get_audience_demographics, so it lacks the dismissal level of a 5.
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 the many analytics-related sibling tools (e.g., get_follower_growth_analytics, get_engagement_trends). There is no mention of alternatives, prerequisites, or scenarios where this tool is preferred, leaving the agent to guess.
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, the description carries the full burden. 'Track' implies a read-only operation, but no details are provided about return format, data source, or limitations. Neither the safety profile nor behavioral traits (e.g., projections are estimates) are disclosed.
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 a single, front-loaded sentence with no fluff. It is appropriately concise, though the brevity sacrifices needed detail. Every word counts, but the message could be more informative without adding bulk.
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?
The tool is relatively simple, but the absence of an output schema means the description must explain what is returned. It does not state whether the result is a time series, a summary, or something else, leaving significant gaps for an analytics tool.
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?
Schema description coverage is 100%, with clear descriptions for period and include_projections. The description adds no additional semantic value beyond what the schema already provides, so the baseline score applies.
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 names a specific resource (follower growth) and action (track), and the word 'projections' hints at unique functionality. However, 'track' is vague and the description doesn't specify what output is produced (e.g., counts, changes over time), limiting differentiation from siblings like get_engagement_trends.
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 given on when to use this tool versus alternatives. The description doesn't mention period or include_projections, nor contrast with other analytics tools like get_audience_demographics or get_engagement_trends.
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 disclose behavioral traits, but it only restates the purpose. It doesn't mention read-only behavior, required permissions, or error handling (e.g., invalid thread IDs or metric names), which is a significant transparency gap.
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 a single, focused sentence with no redundant wording, achieving maximum conciseness. It front-loads the key action and resource, making it easy to parse.
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 tool with no output schema and no annotations, the description is too sparse. It lacks details on what metrics can be requested, the meaning of period values, and the expected output format, making it incomplete for an agent to fully understand the tool's behavior.
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 schema already describes all three parameters with clear descriptions, so the baseline is 3. The description adds nothing about parameter semantics, but the schema covers the basics (thread_id, metrics array, period enum), making the additional description unnecessary.
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 clearly states the tool retrieves performance metrics for a specific thread, using the verb 'get' and specifying the resource. However, it doesn't distinguish from other analytics tools like get_my_insights or get_enhanced_insights, so it loses a point for lack of sibling differentiation.
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 context about when to use this tool instead of alternatives, such as get_my_insights for broader metrics or get_thread_replies for replies. It merely states the function, leaving the agent without guidance on selection criteria.
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, the description carries the full burden. It only says 'Get', implying a read-only operation, but does not disclose return format, pagination, default behavior when optional parameters are omitted, or any rate limiting. This is minimal disclosure.
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 a single front-loaded sentence with no wasted words. It efficiently communicates the core purpose without unnecessary detail.
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?
Given the tool has no output schema and no annotations, the description is too thin. It does not explain what the response looks like, how the category parameter affects results, or when to prefer this over sibling search tools. The many sibling tools highlight the need for more context.
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?
Schema coverage is 100%, with each parameter having a description. The tool description adds no additional meaning beyond what the schema already provides, 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('trending/popular posts') with a scope ('in various categories'). This distinguishes it from sibling tools like search_posts or get_post_likes, though it does not explicitly name alternatives.
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 search_posts or search_by_topics. The description does not mention any exclusions, prerequisites, or context in which trending posts are preferred.
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. It only states the action without revealing behaviors such as pagination, sorting, authentication requirements, privacy filtering, or the shape of the returned list.
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 a single, front-loaded sentence that is easy to parse. While it is concise, it is also under-specified; however, it does not waste words and earns its place as a minimal statement.
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?
With no output schema and no annotations, the description does not convey return format, pagination, error handling, or any list-specific details. For an endpoint that returns a list, this lack of context leaves the agent under-informed about the tool's actual behavior.
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?
Schema coverage is 100% with both 'limit' and 'user_id' having descriptions, so the schema already provides parameter semantics. The description adds no additional insight beyond what the schema states, such as the default behavior of user_id.
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 ('Get') and clearly identifies the target resource ('following list for a user'). It distinguishes from sibling 'get_user_followers' by the direction of the relationship (following vs followers), though it does not explicitly call out that distinction.
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 'get_user_followers' or 'follow_user'. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage solely from the tool name.
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 states the basic search functionality and does not mention any relevant behavioral traits such as result ordering (TOP/RECENT), limit handling, authentication requirements, or that this is a read-only operation. This is a significant gap for a tool lacking 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly conveys the tool's purpose without any filler. Every word contributes, and the structure is as concise as possible while remaining informative.
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 search tool with no output schema and no annotations, the description is insufficiently complete. It fails to mention what the results look like, how pagination or limits work, or how it differs from sibling search tools. The presence of related tools like 'search_by_topics' and 'search_posts' increases the need for contextual guidance that is absent.
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 covers 100% of the parameter descriptions, so the baseline is 3. The description adds minimal semantic value beyond the schema; it echoes the concept of hashtags but does not clarify the 'without #' formatting or the search_type enum behavior. However, since the schema is sufficient, the description does not need to compensate heavily.
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 states the tool's action clearly: 'Search for posts by hashtag or topic tags.' It specifies the resource (posts) and the means (hashtags or topic tags), but does not explicitly differentiate from sibling tools like 'search_posts' or 'search_by_topics' that likely overlap in functionality.
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 about when to use this tool versus alternatives. There is no mention of preferred scenarios, exclusions, or comparisons to search_posts or search_by_topics. The agent is left to infer usage 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not mention read-only status, result ordering, pagination, or any other behavioral traits. The description simply restates the action without additional 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 a single short sentence with no unnecessary words. It is concise, but the brevity borders on under-specification, which slightly reduces the score from 5.
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?
Given the tool has three parameters, no output schema, and no annotations, the description is too terse. It does not explain the scope of the search (e.g., all posts vs. own posts) or the meaning of 'topic tags', which is insufficient for an agent to understand the tool's full behavior and differentiate it from siblings.
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 already documents all three parameters with descriptions, achieving 100% schema description coverage. The description adds no parameter semantics beyond what the schema provides, so the baseline of 3 applies.
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 and resource: 'Search for posts by topic tags'. It clearly conveys the tool's function. However, it does not explicitly distinguish from sibling tools like 'search_by_hashtags' or 'search_posts', which could overlap in scope.
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?
There is no guidance on when to use this tool versus similar search tools. The description does not mention when topic tags are preferred over hashtags or other search methods, leaving the agent without selection criteria.
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, the description carries the full burden, but it adds no behavioral detail. It does not disclose whether results are public, whether auth is required, or any limitations beyond what the parameters hint at.
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?
Very concise, single sentence with zero waste, but it is under-specified. Still, it is appropriately sized and front-loaded.
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?
With no output schema and moderate parameter complexity, the description is too thin to give a complete picture of return values, default behavior, or how this search differs from other search tools.
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?
Schema has 100% coverage with descriptions for all 5 parameters, so baseline 3. The description does not add any additional semantics beyond the schema.
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?
Clear verb+resource: 'search posts'. But lacks scope or differentiation from sibling search tools like search_my_threads, search_by_hashtags, or search_mentions.
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 vs alternatives; no mention of exclusions or preferred contexts. The description is a bare statement with no usage 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?
With no annotations, the description carries full burden. It doesn't disclose whether this is a read-only operation, the default field set, pagination via 'limit', or date filtering semantics. It only states a basic retrieval operation.
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 a single concise sentence, immediately front-loaded with the action and resource. No filler words.
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 four optional params and no output schema, so the description should provide more context about the return format or when to use it. It lacks guidance on the default behavior (e.g., all threads vs recent) and does not distinguish from 'search_my_threads'.
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?
Schema description coverage is 100% for all four parameters (limit, since, until, fields), so the schema already documents their meaning. The description adds no parameter semantics beyond the name 'get_my_threads'.
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 states a clear verb ('Get') and resource ('your own threads/posts'), establishing what the tool retrieves. However, it doesn't differentiate from sibling tools like 'search_my_threads' or 'get_thread_replies', so it's not fully distinct.
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 versus alternatives (e.g., search_my_threads for filtering, get_thread_replies for replies). The description is purely functional and lacks any contextual use case.
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, the description must carry the behavioral transparency burden, but it only states the action. It does not disclose that the tool creates a new public post, potential rate limits, permission requirements, or how reply_control impacts visibility. This lack of context leaves significant uncertainty for the agent.
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 a single sentence with no redundant words. It is concise, front-loaded, and easy to parse.
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?
Given the tool has five parameters and no output schema, the description is too minimal. It does not explain return values, how media_url/media_type interact, or what reply_control means beyond the schema. The agent lacks enough context to fully understand the tool's behavior and outcome.
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?
Schema coverage is 100% for all five parameters, so the description does not need to repeat parameter definitions. The description itself adds no additional parameter-specific meaning, so the baseline 3 is appropriate.
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 function: quoting a post with the user's own text. It distinguishes the tool from siblings like repost_thread (which shares without commentary) and create_reply (which responds directly), 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like repost_thread or create_reply. It implies a use case but does not mention exclusions or selection criteria.
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 disclosing behavioral traits. It only restates the search purpose and does not mention return format, ordering, whether results are limited to public posts, or how 'mention' is determined. This is a significant gap for a search tool with no 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently states the tool's core purpose without wasting 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?
The tool has no output schema and no annotations, so the description should explain what the search returns and how it behaves. It does not mention pagination, default behavior when no parameters are supplied, or how it differs from 'get_mentions'. This leaves the agent with insufficient context for correct invocation.
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?
Schema description coverage is 100%, and each parameter has a clear description (limit, since, until, user_id). The tool description adds no additional meaning beyond the schema, so the baseline of 3 is appropriate.
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 ('Search') and resource ('posts that mention you or specific users'), clearly indicating the tool's function. However, it does not differentiate from the sibling tool 'get_mentions', which likely serves a similar purpose, so it falls short of a 5.
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: use this when you need to find posts mentioning a user. It provides no explicit guidance on when to prefer this over 'get_mentions' or other search tools, nor does it mention exclusions or alternatives, resulting in only implied 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?
The description provides minimal behavioral detail. It does not specify what is searched (e.g., thread content, titles), the output format, or how the limit parameter affects results. With no annotations, the description fails to disclose important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that directly states the tool's purpose without unnecessary details or repetition.
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?
The tool has no annotations and no output schema, and the description does not explain return values or search behavior. This leaves ambiguity about expected results and proper invocation, especially given the simple two-parameter design.
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?
Both parameters are already described in the schema with 100% coverage, so the description adds little beyond the schema. It merely reinforces that 'query' represents keywords, but does not clarify parameter semantics or 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 clearly states the tool's function: searching within the user's own threads using keywords. The specific verb 'search' and resource 'your own threads' distinguishes it from general search tools like search_posts.
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. The description does not mention scenarios, exclusions, or alternative tools, leaving the agent to infer usage from the name and 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. It does not disclose that deletion is irreversible, any cascading effects on replies, or permission requirements. The description is a bare statement of the action without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It is front-loaded, efficiently conveying the purpose in minimal space.
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 fully described in the schema, but the lack of any behavioral warnings (e.g., irreversibility) and absence of annotations leaves some context missing. It is minimally complete but not thorough.
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?
Schema description coverage is 100% for the single parameter thread_id, which already explains what it is. The description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Delete') and resource ('thread'), clearly indicating the operation. It distinguishes this tool from siblings like 'publish_thread' and 'manage_reply' by being the only delete operation for threads.
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 exclusions, and no context about prerequisites. It simply states the action, leaving the agent to infer usage from the name.
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 alone must convey behavior. It clearly states the read operation, but adds no detail about pagination, ordering, or response structure. It is not misleading, but it is minimal for a tool without 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of six words, front-loaded and free of unnecessary content. It is highly concise and to the point.
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 two optional parameters, and the description adequately states its function. However, it lacks any differentiation from the sibling 'search_mentions' and provides no hints about return format or edge cases, making it only minimally 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 provides descriptions for both parameters (limit and fields), achieving 100% coverage. The tool description adds no extra parameter semantics beyond what the schema already documents.
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 clear verb 'Get' and a specific resource 'threads where you are mentioned', making the core purpose unambiguous. However, it does not explicitly distinguish this from sibling tools like search_mentions, so it misses full differentiation.
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 search_mentions or get_my_threads. There are no exclusions, preferred scenarios, or context hints beyond the basic purpose.
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?
The description is minimal and does not disclose behavioral traits beyond the basic operation. With no annotations available, the description fails to mention important details such as pagination (especially given the 'limit' parameter), ordering of results, whether the list includes the user's own like, or any rate limits. The read-only nature is implied but not explicit.
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 a single short sentence that is direct and easy to parse. Every word contributes to the meaning, and there is no unnecessary verbosity.
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 relatively simple, and the schema covers the parameters, but there is no output schema and no additional context about the return value structure or edge cases. The description alone may be sufficient for a basic 'get list' operation, but it lacks the richer detail seen in higher-scoring tools (e.g., pagination behavior, filtering options, or sibling alternatives).
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 covers 100% of parameters (post_id and limit) with descriptions, so the baseline is 3. The description adds little beyond the schema, merely indicating the result is a 'list of users', which is already obvious. No additional context about parameter formats, defaults, or relationships is provided.
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 'Get list of users who liked a post' provides a specific verb ('Get') and resource ('list of users who liked a post'), clearly distinguishing it from sibling tools like like_post/unlike_post and other read operations. It is concise and unambiguous.
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, nor are any exclusions mentioned. The description only states what it does, not when it should be preferred over similar list-type tools or whether there are prerequisites such as authentication or ownership.
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 says 'Get followers list' with no details on pagination, privacy restrictions, authentication, or output shape. This is a significant gap even for a read operation, as the agent cannot anticipate behaviors like default user_id handling or limit semantics beyond the schema.
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 a single concise sentence with no redundant words. It efficiently communicates the core purpose without unnecessary elaboration, fitting the simplicity of the tool.
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 read-only tool with full schema coverage, the description is minimally adequate. However, it lacks any mention of return value details, pagination behavior, or edge cases like private accounts. Given the absence of an output schema and annotations, the description should do more to explain what the agent can expect from the call.
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 already has 100% description coverage for both parameters (limit and user_id), so the baseline is 3. The tool description itself adds no parameter-specific information, neither supplementing nor clarifying what is already structured.
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 action (Get) and the resource (followers list) for a user. It distinguishes from sibling tools like get_user_following by specifying 'followers' rather than 'following', and from analytics tools by focusing on the list itself.
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 such as get_user_following or get_follower_growth_analytics. There is no mention of exclusions, prerequisites, or common scenarios, leaving the agent to infer usage solely from the name.
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, the description carries the full burden of behavioral transparency. It only states the action without disclosing side effects, permission requirements, reversibility, or impact on public visibility, which 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the core action and resource, earning a high score for conciseness.
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 two-parameter mutation, the description is minimally adequate, but it omits details such as whether hiding/showing affects public visibility, ownership constraints, or response behavior. Given no annotations or output schema, more context would improve completeness.
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 schema already documents both parameters completely (reply_id and hide). The description adds no parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate. The phrase 'your threads' implies ownership but does not clarify parameter values.
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 a specific verb-action (hide/show) on a specific resource (replies to your threads). It distinguishes this tool from sibling reply-related tools like create_reply or get_thread_replies by indicating a moderation context on the user's own threads.
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. It does not mention prerequisites (e.g., thread ownership) or contrast with other reply-related tools, leaving the decision to the agent based solely on the action itself.
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 only says 'Unfollow a user' without disclosing effects, permission requirements, reversibility, or response behavior, which is insufficient 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 a single, front-loaded sentence with no wasted words. 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.
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 schema is complete, but with no annotations and no mention of outcomes or alternative tools, the minimal description leaves some gaps. It is adequate but not thorough.
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 fully documents the single user_id parameter with a description, achieving 100% coverage. The tool description adds no additional meaning beyond what the schema already provides, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Unfollow' with a clear resource ('a user'), and it is distinguishable from sibling tools like follow_user and block_user. It states exactly what the tool does.
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 follow_user or block_user. There are no context hints, prerequisites, or exclusions.
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 states only the basic action and does not mention side effects, permissions, rate limits, or what occurs on failure. As a mutation tool, this lack of detail 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the verb and resource. Every word contributes, and there is no filler or redundancy.
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?
The tool has no output schema and no annotations. The description does not mention return values, side effects, or usage limitations. While the input schema is well-defined, the overall definition is too sparse for an agent to fully anticipate the tool's behavior and results.
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?
Schema description coverage is 100%: both parent_thread_id and replies have descriptions that explain their roles. The tool description adds little beyond confirming that replies are connected; the schema already provides the necessary parameter 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 specifies the action ('Create') and the resource ('a thread chain'), and the parenthetical '(multiple connected replies)' clarifies what the tool does. This distinguishes it from sibling tools like create_reply (single reply) and publish_thread (creating a new thread).
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 creating multiple connected replies, but it offers no explicit guidance on when to choose this tool over alternatives like create_reply or publish_thread. No when-not-to-use conditions or alternative tool names 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 carries the full burden. It implies a read-only operation via 'get', but it does not disclose any limitations such as pagination, whether nested replies are included, the format of the 'fields' parameter, or any ownership restrictions. The phrase 'your specific thread' hints at an ownership constraint, but this is ambiguous and not fully explained.
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 a single sentence with no superfluous words. It is highly concise and front-loaded with the core 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?
This is a simple get tool with no output schema and no annotations. The description is minimally viable: it states the purpose and implies an ownership filter, but does not provide additional context like return format, edge cases, or guidance on the 'fields' parameter. Given the large number of sibling tools, a bit more context would improve completeness.
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?
Schema description coverage is 100%, and both parameters have descriptions: 'thread_id' and 'fields'. The tool description adds no additional meaning beyond what the schema already provides. Baseline for full schema coverage is 3.
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 replies to your specific thread', which is a specific verb+resource+scope. It distinguishes itself from sibling tools like get_my_threads (which gets threads), manage_reply (which manages replies), and create_reply (which creates replies).
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: use when you need to retrieve replies for a thread you own. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. With multiple related sibling tools, more explicit guidance would be helpful.
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 only states the basic search functionality without disclosing behavior such as partial vs exact matching, pagination, sorting, or return format. For a read-only tool, the lack of explicit safety info is a gap.
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 a single concise sentence with no fluff. It front-loads the action and subject, making it immediately clear and efficient.
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 search tool, the description covers the essential purpose, but with no annotations and no output schema, it lacks information about the return value or behavior. It is minimally viable but leaves room for clarification.
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?
Schema description coverage is 100% and both parameters are adequately described ('Username or display name to search for' and 'Number of users to return'). The description adds no extra 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Search' with the resource 'users' and clarifies the search criteria ('by username or display name'). This clearly distinguishes from sibling tools like search_posts or search_mentions, which target different resource types.
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: when you need to find users by name. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context is understandable but not fully specified.
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 only states the core action ('Remove like') without disclosing side effects, permissions, idempotency, or what happens if the post is not liked. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action verb, and contains zero waste. Every word earns its place.
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 one-parameter mutation tool, the description is minimally viable. There is no output schema, but the operation is straightforward. However, it lacks context about return values, error conditions, or authentication requirements, which could be important for the agent.
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?
Schema coverage is 100%, with post_id fully described as 'ID of the post to unlike'. The description adds no additional parameter context, but since the schema already covers the single parameter, a baseline score of 3 is appropriate.
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 'Remove like from a thread/post' uses a specific verb ('Remove') and resource ('thread/post'), clearly stating the action. This distinguishes it from sibling tools like like_post (the inverse operation) and get_post_likes (viewing likes).
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?
Usage is implied by the description: it is used to remove a like from a post. However, there is no explicit guidance on when to use it versus alternatives or any exclusions, such as if the post is already unliked. The context is simple enough that implied usage is adequate.
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 disclose behavioral traits. It only notes the repost must have been 'previously shared', implying an ownership/precondition, but does not mention authentication requirements, idempotency, effects on the original post, or error behavior. This is insufficient 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 a single, front-loaded sentence with no filler or redundancy. It achieves clarity with minimal words.
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 one-parameter action, the description gives a minimal viable explanation. However, it lacks details on side effects, success/failure behavior, and whether the repost must belong to the authenticated user. Given no output schema and no annotations, a bit more context would improve completeness.
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 schema already provides 100% coverage with a clear description for post_id ('ID of the post to unrepost'). The tool description adds nothing beyond the schema, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language ('Remove a repost you previously shared') that clearly identifies the action and resource. It distinguishes from sibling tools like delete_thread (for original posts) and unlike_post (for likes), making the intent unmistakable.
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 implies the tool is for removing previously shared reposts, which is a clear use case. It does not explicitly mention alternatives or exclusions, but the context from the name and description makes when-to-use apparent. Slight deduction for not explicitly differentiating from delete_thread or unlike_post.
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?
No annotations are provided, so the description carries the full burden of disclosing behavior. The verbs 'validate', 'check', and 'verify' clearly signal read-only, non-destructive operations. It does not detail error behavior or return format, but for a simple validation tool, the core behavior is sufficiently transparent.
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 a single, concise, front-loaded sentence that lists the key actions without unnecessary detail. Every word contributes to understanding the tool's purpose, and there is no redundancy or filler.
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?
With no output schema and no annotations, the description does not explain what the tool returns or what happens on failure. While the tool is simple, the description omits these contextually important details. It covers the main purpose adequately but leaves a gap in expected outcomes.
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 covers 100% of parameters with descriptions, so the schema already explains 'check_scopes' and 'required_scopes'. The description adds no additional parameter semantics beyond what the schema provides, which meets the baseline but does not exceed it.
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's purpose with specific verbs: 'Validate access token, check scopes, and verify business account setup'. It distinctly identifies the resource (access token, scopes, business account) and differentiates from sibling tools by focusing on setup validation rather than data retrieval or posting.
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 the tool is used to validate setup prerequisites, likely before using other API tools. However, it does not explicitly state when to use it versus alternatives, nor does it mention exclusions or prerequisite conditions. No alternative tools are referenced, leaving the agent to infer usage context.
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 provided, so the description bears the full burden. It indicates a read-only operation ('Get') with no side effects, which is sufficient for a simple retrieval. However, it doesn't disclose response format, auth requirements, or potential edge cases, but for a straightforward profile getter this is acceptable.
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 a single, succinct sentence with no fluff. It conveys the core purpose efficiently, earning a top score for 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?
For a simple tool with one optional parameter and no output schema, the description adequately conveys what the tool does. The absence of an output schema could warrant mentioning return value contents, but the phrase 'profile information' gives sufficient context. The description is complete enough for straightforward use.
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 100% coverage: the only parameter 'fields' is described as 'Profile fields to retrieve'. The tool description adds no additional parameter semantics, so the baseline of 3 applies.
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 'Get' and clearly identifies the resource as 'your own Threads profile information', which distinguishes it from sibling tools like get_my_threads or get_my_insights. It precisely states the scope (own profile) and 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 contextual phrase 'your own' clarifies that this tool is for retrieving the authenticated user's profile, not other users. While it doesn't explicitly name alternative tools, the context is clear and no exclusions are stated. This meets the 'clear context, no exclusions' level.
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 of behavioral disclosure. 'Check' strongly implies a read-only operation, but the description does not explicitly state that it has no side effects, does not consume quota, or that it returns data without altering state. It provides minimal but non-misleading behavioral information.
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 a single, concise, and front-loaded sentence that clearly states the tool's purpose. Every word earns its place, and there is no redundancy or extraneous detail.
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 tool with no parameters and no output schema, the description provides adequate context for invocation. It clearly identifies what the tool does, though it could be slightly more detailed about the nature of the returned quotas (e.g., daily post limits vs. rate limits), which would improve completeness 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 coverage is 100% (vacuously). No parameter semantics are needed, and the description adds no parameter information, which is acceptable since there is nothing to clarify.
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 ('Check') with a clear resource ('your current publishing quotas and limits'). It is easily distinguishable from sibling tools that perform actions (publish_thread, schedule_post) or retrieve other profile data (get_my_profile).
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 this tool is used to check publishing limits before posting, but it does not explicitly state when to use it or mention alternatives. There are no exclusions or context signals provided, so the usage context is only weakly implied.
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:

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

Score Badge

Copy to your README.md:

[![threads-mcp MCP server](https://glama.ai/mcp/servers/baguskto/threads-mcp/badges/score.svg)](https://glama.ai/mcp/servers/baguskto/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/baguskto/threads-mcp'

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