Socials MCP

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation4/5
Most tools have clear, specific purposes, with platform prefixes (x_, linkedin_, instagram_) helping distinguish actions. A few overlapping tools like socials_get_feed vs socials_get_page_content and socials_engage_post vs socials_linkedin_engage could cause confusion, but descriptions clarify the intended use.
Naming Consistency3/5
The consistent 'socials_' prefix helps, but naming conventions are mixed: some tools use verb_noun (get_feed, create_post, open_tab), while others use platform_noun (linkedin_profile, x_search) or platform_verb (linkedin_engage). This inconsistency makes the set less predictable, though still readable.
Tool Count2/5
With 36 tools, the server feels over-scoped. While it covers multiple platforms (X, LinkedIn, Instagram, YouTube) plus tab management and diagnostics, the count exceeds the typical comfortable range and many tools are platform-specific, making the set heavy to navigate.
Completeness3/5
The tool set covers a wide range of social media actions, including search, posting, engagement, and profile retrieval. However, notable gaps exist: no post deletion/editing, no LinkedIn original post creation, and limited Instagram functionality (only create post). These missing operations may hinder full workflow completion.
Average 4.1/5 across 36 of 36 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- Last stable release on June 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must disclose behavior. It mentions that refresh=true bypasses the cache and force-refreshes from PostHog, but it doesn't state whether the tool is read-only, whether it has side effects, or what the authentication requirements are. This is insufficient for a diagnostic tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with the main action in the first sentence and parameter usage in the second. It is concise, front-loaded, and contains no 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?
The tool is simple with one optional parameter, but without an output schema the description should explain the return structure or provide more context. It lists the categories of diagnostics but does not describe the shape of the response or any preconditions. Combined with the lack of behavioral details, the description is only partially 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 already describes the refresh parameter with the same information ('Force refresh feature flags from PostHog (bypasses cache)'). The description repeats this without adding new meaning, so it scores at the baseline of 3 given 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves diagnostics information including health metrics, engagement score, and feature flags. It uses a specific verb ('Get') and identifies the resource, but does not explicitly differentiate from sibling tools like socials_health_check, so it gets a 4.
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 socials_health_check. It only explains the refresh parameter, which is about parameter usage, not tool selection. Thus, the agent is left without direction on choosing this tool over others.
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 responsibility for behavioral disclosure. It only states the action without mentioning side effects, safety (read-only vs. destructive), authentication requirements, or what happens when the pinned tab is absent. This is a notable gap for a tool that likely affects browser state.
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, direct and free of unnecessary words. It immediately communicates the core action and the parameter condition, making it highly concise and efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional parameter, no output schema), so the description covers the essential action. However, it lacks details about error cases, prerequisites, or consequences of reloading, which would be needed for full completeness without annotations. 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 schema already fully describes the parameter (100% coverage) with 'Optional. If omitted, reloads the pinned agent tab.' The description adds no additional meaning beyond restating 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.
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: reload the pinned agent tab, or a specific tab if tab_id is provided. It uses a specific action verb ('reload') and identifies the target resource ('pinned agent tab'), distinguishing it from sibling tools like open_tab or focus_agent_tab.
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 like socials_open_tab or socials_navigate. The only conditional is 'or tab_id if provided,' but there is no explanation of prerequisites (e.g., what if no pinned tab exists) or scenarios where reload is 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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the navigation intent but fails to mention side effects (e.g., browser tab navigation), requirements (e.g., authenticated LinkedIn session), or error handling for invalid page numbers.
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 front-loads the verb and object, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is mostly adequate. However, it omits any prerequisites (e.g., must be on a LinkedIn search results page) and doesn't clarify what happens after navigation. Still, for its minimal complexity, it does not leave major gaps.
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 describes the 'page' parameter as 'Page number to navigate to (1-based)', achieving 100% schema description coverage. The description adds no additional semantic information beyond what is already in 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 clearly states the action ('Go to') and the resource ('a specific page number of LinkedIn search results'). It distinguishes itself from sibling tool 'socials_linkedin_next_page' by emphasizing navigation to an arbitrary page rather than sequential paging.
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 word 'specific' implies use when a target page number is known, as opposed to the sibling 'next_page' tool. However, the description offers no explicit when-to-use or when-not-to-use guidance, nor does it mention the need for an existing search results session.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool opens a 'Filters' popup, clicks labels, and waits for reload between filters, providing useful insight into the UI automation. However, it does not disclose side effects, prerequisites, or failure modes beyond the platform constraint.
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?
Two sentences, front-loaded with the core purpose, followed by implementation specifics. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides a clear overview and current platform, but given there is no output schema, it does not explain what the tool returns, error behavior, or prerequisites (e.g., being on a search results page). The schema covers parameters, but the description lacks return/error semantics, which is a gap for an automation 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 coverage is 100%, so baseline is 3. The description adds slight context by explaining that it 'clicks labels' (mapping to the filters array) and 'waits for reload between applied filters' (implying sequential application). It does not add detail beyond the schema, but the schema is already complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: 'Apply filters on a search results page using a standard interface.' It names the resource (search results page) and the operation (apply filters), and further clarifies the current implementation for YouTube search results. This clearly distinguishes it from sibling tools like search or profile tools.
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 YouTube search results by stating 'Current implementation: YouTube search results', but it does not explicitly mention when to use this tool vs alternatives, nor does it name any alternative tools or exclusions. The usage is inferred rather than directly stated.
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 provided, the description carries the full burden. It does disclose the Pro access requirement, which is a meaningful behavioral constraint, and implies a read-only operation via 'Get'. However, it does not mention rate limits, return format, or other side effects, leaving a transparency gap for a no-annotation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences, front-loaded with the core action and scope. The second sentence adds the Pro access requirement without redundancy. 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?
The tool has only two parameters and no output schema, so the description must convey enough about the return value. It states 'detailed context including replies' but remains vague about what else the context includes or how replies are structured. For a simple tool this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with both 'platform' and 'post_url' clearly described in the schema. The description mentions 'specific post', which aligns with 'post_url', but adds no additional parameter-level detail beyond what the schema already provides, so it meets the baseline.
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 'Get' with a clear resource ('detailed context for a specific post') and scopes it further with 'including replies'. This distinguishes it from feed-level tools like socials_get_feed, though it does not explicitly name sibling alternatives, so it lacks full 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of when to use this tool is clear: to retrieve detailed context and replies for a single post. The 'Requires Pro access' statement adds a prerequisite but does not explicitly state when not to use it or mention alternatives, so it's a 4 rather than 5.
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?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It goes beyond the basic function by explaining the non-obvious behavior that it reads the pinned agent tab, not the visible tab, and that it works across Chrome windows. This is valuable context that an agent would otherwise not know. It also discloses the Pro access requirement. This is a strong effort, though it omits details like rate limits or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the core action, and every word adds value. It states the action, a prerequisite, and a critical behavioral quirk without any filler. This is a model of conciseness for a structured tool description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a simple tool with two parameters, no output schema, and no annotations, the description covers the critical points: purpose, prerequisite, and the unusual pinned-tab behavior. It does not describe the return format or pagination, but for a 'get feed' tool this is not essential. The description is adequate for an agent to invoke it correctly, though not exhaustive. A score of 4 reflects that it is complete enough for the tool's 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 already provides full documentation for both parameters (count, platform) with descriptions and an enum for platform. The description adds no additional parameter-level semantics, so it relies entirely on the schema. If the schema did not exist, this would be a problem, but with 100% schema tag coverage, 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 begins with 'Get recent posts from a social media feed', which clearly identifies the verb and resource. It does not explicitly differentiate from siblings like socials_get_post_context, but the mention of 'feed' and 'recent posts' is sufficiently specific for an agent to distinguish it from related tools.
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 provides usage context by noting that it requires Pro access and that it reads the pinned agent tab (set by socials_open_tab). However, it does not explicitly state when to prefer this tool over alternatives or provide exclusions. The implied usage is clear, but explicit guidance comparing to siblings is missing.
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 says 'Check connection status' and gives a recovery flow, but does not state whether the check is read-only, what it returns, or any side effects. The recovery flow hints that the tool can fail, but does not explain the tool's own behavior or what the success/failure indication looks like.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, the first stating the purpose and the second providing a structured recovery flow. It is front-loaded and every sentence earns its place. The numbered recovery steps are concise and easy to follow without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters, no output schema, no annotations), the description covers the core purpose, the expected next action (use socials_open_tab), and a detailed recovery flow. It lacks an explicit description of what the tool returns or how status is reported, but for a simple check, the provided context is mostly sufficient.
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 input schema is empty, so the schema coverage is vacuously high. The baseline for 0 params is 4, and the description adds no parameter information because none is needed. The description's focus on usage and recovery is sufficient.
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 'Check connection status' with a clear verb and resource. It distinguishes itself by framing this as a preflight check before using socials_open_tab, and the recovery flow ties it to access-related siblings. However, it does not explicitly differentiate from socials_health_check or socials_diagnostics, which could have overlapping purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states 'After confirming access, use socials_open_tab...' and provides a numbered RECOVERY FLOW with alternative tools (socials_refresh_auth, socials_restart_bridge) and a user action. This gives clear when-to-use and what-to-do-on-failure guidance, going beyond a simple statement of purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that 'like' is a toggle, and warns to only use when the user explicitly wants these actions. However, it does not disclose potential side effects like repost being public or quote_repost creating a new visible post, which is important 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 two sentences, front-loaded with the main purpose, followed by a compact action list and an important usage note. No filler or redundant content—every sentence serves a purpose.
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 mutation tool with no output schema, the description covers the core usage and action types well. However, it omits return/error semantics and the side effects of repost/quote_repost. Given the social context and potential public actions, more detail would be warranted for full 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%, so baseline is 3. The description adds the clarification that 'like' is a toggle, which is not in the schema, and references the post_id source. This is slight added value over the schema, but not substantial enough to raise beyond baseline.
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: 'Engage with a LinkedIn post' with specific actions like, repost, and quote_repost. It distinguishes from siblings by being LinkedIn-specific and enumerating the exact engagement actions, making it easy to select over generic tools like socials_engage_post.
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?
Provides explicit context: 'Pass post_id from socials_get_feed' and 'IMPORTANT: Only use when the user explicitly wants these actions.' This sets a clear trigger and prerequisite. However, it does not explicitly mention alternatives or when not to use it (e.g., for replies), so it lacks a full when-not/alternatives list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discloses critical behavioral traits: 'read-only' and 'no request sent', plus return value examples. This provides clear expectations for side effects and outcomes, though it omits auth requirements or potential errors.
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 purpose, then adds return values and safety note. No redundant or filler content; every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, yet the description compensates by listing return values and emphasizing the read-only nature. It is sufficiently complete for an agent to invoke correctly, though listing more possible statuses (e.g., 'pending_received') would enhance 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 coverage is 100%, with the single parameter 'profile_url' clearly documented with an example. The description adds no additional parameter semantics 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Check connection status') with a specific resource ('a LinkedIn user'), and explicitly differentiates itself from the sibling 'socials_linkedin_connect' by noting 'read-only, no request sent'. It also lists expected return values, making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking status before connecting, but does not explicitly state when to use this tool versus alternatives like 'socials_linkedin_connect'. The phrase 'no request sent' hints at a non-destructive alternative but lacks direct guidance on tool selection.
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 carries the full burden. It discloses the return payload (array of people with fields and pagination info) but doesn't explicitly state whether the operation has side effects, requires prior search setup, or what happens if no search page is active. This is adequate but not rich.
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?
Two sentences, front-loaded with the primary action, and each sentence provides essential information about the return value and pagination. No redundancy or filler.
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?
Despite lacking an output schema, the description enumerates the returned fields and pagination details, giving a complete picture of the output. For a simple read tool with one optional parameter, this is sufficient, though failure conditions and prerequisites are not covered.
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 single parameter 'count' is fully described in the schema with its maximum limit and default value, giving 100% schema coverage. The tool description adds no additional parameter information, 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' and resource 'people results from current LinkedIn people search page'. This clearly distinguishes it from sibling tools like socials_linkedin_people_search (which initiates a search) and socials_linkedin_next_page (which navigates).
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?
Phrase 'current LinkedIn people search page' implies a prerequisite of an active search, providing clear context for when to use the tool. It doesn't explicitly name alternatives or exclusions, but the sibling tools are evident and the context is sufficient.
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 carries the full burden. It discloses an important behavioral trait: the search itself does not return results, requiring a subsequent call to socials_linkedin_get_people. However, it does not mention side effects, permissions, or whether the operation is read-only, leaving some gaps in transparency.
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 three short sentences, each adding needed information: the purpose, the filters, and the follow-up tool. No filler words and the most important information is front-loaded. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there is no output schema and the tool has a simple two-step workflow, the description is quite complete. It tells the agent what the tool does, what filters are available, and how to proceed to get results. It does not explain edge cases like making a query optional, but this is a minor gap for such a straightforward 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 covers all three parameters (query, network, actively_hiring) with descriptions. The description adds minimal value by listing the filters and their types (1st/2nd/3rd connections), but it essentially repeats the schema rather than providing deeper semantics or examples.
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 and resource ('Search for people on LinkedIn') and clearly distinguishes it from the sibling tool socials_linkedin_get_people by explaining that this tool performs the search while the sibling retrieves results. It also mentions the filter options, further clarifying its scope.
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 gives clear workflow context: it explicitly says to use socials_linkedin_get_people to get results after search, which tells the agent how to sequence these tools. It does not explicitly mention when not to use this tool or compare it to socials_linkedin_posts_search, but the context is sufficient for typical usage.
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 burden of disclosing behavior. It reveals that the tool navigates to search results rather than returning data directly, which is important. However, it does not disclose whether it modifies any state (e.g., typing into a search box, clicking filters) or mention authentication or rate limits. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose, and includes a concise workflow. Every word adds value, with no redundancy or filler.
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 one-parameter tool with no output schema, the description is complete: it explains the action, the destination (filtered search results), and the follow-up steps. It lacks edge-case handling (e.g., empty results) but is sufficient 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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already provides a description with examples for the query parameter. The tool description adds no additional parameter semantics beyond restating 'Search for posts.' Baseline 3 is appropriate as the schema handles the heavy lifting.
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: 'Search for posts on LinkedIn.' It specifies a distinct resource (posts) and distinguishes from sibling tools like socials_linkedin_people_search. The added detail about navigating to filtered search results further clarifies the action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear next-step guidance: 'After success, use socials_get_feed to read visible posts, then socials_linkedin_engage or socials_quick_reply to interact.' This gives a usage workflow but does not explicitly exclude alternative tools or state when not to use this tool, so it falls short of a 5.
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 carries the full burden. It discloses 'auto-navigates' as a behavioral trait, implying a side effect on the current tab, and lists extracted fields. However, it does not mention authentication requirements, error handling, or potential impact on the browser session, which are relevant for an automated 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, well-structured sentence that front-loads the core purpose and immediately follows with the required input and expected output. No redundant words or filler; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description adequately covers the return values by listing the extracted fields. It lacks a note on whether navigation changes the current tab or opens a new one, and error behavior, but given the low complexity, the description is mostly 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% with a clear description and example for profile_url. The description merely repeats 'Pass profile_url' without adding meaning beyond the schema. The schema already provides the necessary parameter details, so the description adds no extra semantic value.
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: 'Get a LinkedIn profile' with a specific verb and resource. It lists the exact data fields extracted (name, headline, about, experience, education, skills, contact info) and distinguishes it from sibling tools like socials_x_profile (Twitter) and socials_linkedin_people_search (search).
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 gives clear usage context: pass profile_url to retrieve profile details. It does not explicitly name alternatives or exclusion cases, but the tool's specificity makes the intended use unambiguous. Sibling tools are distinct enough that no further guidance is necessary.
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 carries the full burden. It discloses that both system and user-created personas are included, which is useful behavioral context. However, it does not mention any side effects, authentication needs, or result format limitations.
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, well-structured sentence that directly conveys the tool's purpose and key scope. No filler or redundant information.
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 parameterless listing tool, the description adequately explains what it returns. It does not describe the structure of each persona or pagination behavior, but given the tool's simplicity and lack of output schema, the description is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to explain parameter details. It instead clarifies the scope of the returned list (system and custom personas), adding meaning beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available personas for content generation, with a specific verb (list) and resource (personas). It also differentiates from sibling tools by focusing on personas, which is unique among the listed siblings.
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 phrase 'for content generation' implies the usage context but does not explicitly state when to use this tool versus alternatives or provide exclusions. No sibling alternatives are mentioned, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 discloses a key nuance (does not require the tab to be focused) and implies the effect of loading more posts. However, it does not mention side effects, return values, or edge cases, leaving some gaps.
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, information-dense sentence that immediately conveys the action, target, and a valuable qualifier. There is no wasted wording.
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 scroll tool with two optional, well-documented parameters, the description covers the core action and a critical behavioral condition. It doesn't address return values, but the simplicity of the tool makes this less critical.
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% coverage with clear descriptions and defaults for both parameters (amount and direction). The description does not add any 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 the specific verb 'Scroll' and clearly identifies the resource ('pinned agent tab') and the intended outcome ('load more posts'). The additional note about not requiring focus further distinguishes it from sibling tools like socials_get_feed or socials_navigate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool: to load more posts on the pinned agent tab, and it notes that the tab does not need to be focused. However, it does not explicitly discuss alternatives or exclusions, so it falls short of a 5.
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 disclose behavioral traits, but it does not explain side effects (e.g., whether it changes focus, replaces the previous agent tab, or performs any navigation/seeking). 'Pin' implies a state change but the description does not clarify the impact on the browser or other tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary purpose, and includes a direct instruction for the parameter. No filler or redundancy.
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 one-parameter tool with no output schema, the description covers the core action and parameter source. It does not explicitly state when to use vs. alternatives, but given the sibling tool names and the clear 'existing tab' wording, the context is sufficiently complete for an agent to select and invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already defines tab_id with a description, so schema coverage is 100%. The description adds valuable semantics by specifying the source of the tab_id ('from socials_get_active_tab'), which helps the agent retrieve the correct value beyond what the schema provides.
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 with a specific verb+resource: 'Pin an existing tab as the agent tab'. It distinguishes from siblings like open_tab (which opens a new tab) and get_agent_tab (which retrieves the current agent tab), and provides concrete examples (X, LinkedIn, Reddit, YouTube).
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 when to use the tool ('existing tab') and how to obtain the required tab_id ('Pass tab_id from socials_get_active_tab'). It lacks explicit exclusions or alternatives, but the context is clear enough for an agent to know this is for setting an already-open tab as the agent tab.
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 must carry the behavioral burden. It does disclose a prerequisite (navigate first) and the return content (likes, follows, reposts, mentions with timestamps). However, it is ambiguous whether the tool itself navigates or expects prior navigation, and it lacks details on auth, side effects, or error behavior. This is a moderate level of 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 two sentences, front-loaded with the core purpose, and includes essential context (navigation requirement and output contents) without wasted words.
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 parameter and no output schema, the description covers the main behavior, prerequisites, and return values. The only gap is the ambiguous navigation requirement (whether the tool navigates itself or expects a prior call), which prevents a perfect score.
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 100% coverage of the single 'count' parameter with a clear description (default 10, max 20). The tool description does not add any additional parameter semantics, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get notifications from X (Twitter)' with a specific verb and resource. It also enumerates the types of notifications returned (likes, follows, reposts, mentions) with user info and timestamps, distinguishing it from siblings like socials_x_search or socials_get_feed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear precondition: 'Must navigate to https://x.com/notifications first.' This tells the agent when it's appropriate to use the tool (when on the notifications page). However, it does not explicitly mention alternatives or exclusions, though sibling names imply differentiation.
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 burden of behavioral disclosure. It explicitly states the need to always confirm with the user before posting, which is a key behavioral trait. However, it does not disclose other relevant behaviors such as the action being public, rate limits, potential errors, or reversibility. This adds some context but leaves significant gaps.
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 highly concise, using two sentences to convey the action, key parameters, and a critical safety instruction. It is front-loaded with the primary purpose and contains no unnecessary words. Every sentence provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 parameters, no output schema, no annotations), the description is fairly complete. It covers the action, the source of the post ID, the content parameter, and a critical user-confirmation requirement. It does not mention the return value or media parameter, but these are covered by the schema or are non-essential for invocation. Slightly more detail about consequences would push it to a 5.
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 has 100% coverage with descriptions for all three parameters. The description adds minimal extra value by specifying that post_id comes from socials_get_feed and that content is the quote text. This slight clarification does not significantly exceed the baseline set by the schema, so a 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 clearly states the action 'Quote tweet a post on X' with a specific verb and resource. It also identifies the key parameters (post_id and content) and differentiates itself from sibling tools like socials_create_post and socials_engage_post by explicitly focusing on quote tweeting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it indicates the tool is for quote tweeting and references socials_get_feed as the source for post_id, establishing a dependency. It does not explicitly mention alternatives or exclusions, but the instruction to confirm with the user adds a practical usage rule. This is clear guidance, though not fully explicit about when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses a non-obvious behavior ('Does not require that tab to be active') but omits return value, side effects, or permissions. Some behavioral context is provided, but it is incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every word adds information. The second sentence contributes an important behavioral constraint, making it appropriately sized with no 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?
The tool is low-complexity with only two parameters, and the description covers the core action and tab selection logic. However, without an output schema, it does not explain what the tool returns or indicates success, leaving a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, giving a baseline of 3. The description adds extra value by referencing socials_open_tab's URL patterns and giving a concrete YouTube search example, which enriches the meaning of the 'url' parameter beyond the schema's generic description.
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 (navigate), the target resource (pinned agent tab or tab_id), and the destination (URL). It also adds scale by noting the tab need not be active, which distinguishes it from tools like socials_reload_tab or socials_focus_agent_tab.
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 when to use this tool (when navigating an existing pinned tab) and references socials_open_tab for URL patterns, which aids in selecting the right tool. However, it does not explicitly mention when not to use it or name alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the UI automation steps (opens compose dialog, fills text, attaches media, clicks Post) and the environment prerequisite (agent tab on X with left nav visible). It also highlights the need to confirm with the user. While it doesn't discuss reversibility or failure modes, the key behaviors are 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 compact, with two sentences capturing the core action and prerequisites, plus a prominent IMPORTANT note for user confirmation. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's UI automation nature, the description covers prerequisites, actions, and a safety check (confirmation). The schema fully describes parameters. It doesn't mention post-publish result, but with no output schema and a straightforward create operation, the essential context is present.
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%, so baseline is 3. The description mentions optional media attachment and filling text, but these are already covered by the schema's parameter descriptions. It adds no new parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it publishes a new original post on X (not a reply), distinguishing it from reply and quote tweet siblings. It also specifies the pinned agent tab context, making the tool's 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clarifies when to use it by excluding replies and noting it's for original posts, implicitly differentiating from socials_quick_reply and socials_x_quote_tweet. It also provides situational prerequisites (pinned tab on X, left nav visible) and a mandatory user confirmation step. However, it does not explicitly name alternative tools for other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosure. It reveals useful behavioral traits: 'auto-scroll' on search results and the ability to 'switch comment sort (top/newest) before scraping.' These go beyond basic functionality and help set expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: one sentence states the core purpose, a second elaborates on YouTube-specific behaviors. Every sentence earns its place without unnecessary fluff.
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?
Despite lacking an output schema, the description explains what is returned ('video cards', 'structured video metadata plus comments') and mentions configurable options like comment sorting. It does not cover error handling or limits, but for a scraping tool of moderate complexity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with each parameter having a clear description. The tool description does not add extra parameter meaning beyond the schema; it only indirectly references comment_sort. Thus, the schema does the heavy lifting, so 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 clearly states the tool's function: 'Get structured content from the pinned agent tab.' It further distinguishes between YouTube search and watch page behaviors, making it specific and different from sibling tools like socials_get_active_tab or socials_get_feed.
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?
It provides clear context for when to use the tool, explaining what happens on YouTube search vs. watch pages. However, it does not explicitly mention alternatives or when not to use it, though the behavior descriptions implicitly guide usage.
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 present, so the description carries full burden. It discloses auto-navigation to the profile, return statuses, and the critical requirement to confirm with the user before sending. This is useful behavioral guidance beyond basic tool use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (about 40 words) and front-loaded with the main action. The IMPORTANT note is critical and clearly highlighted. No wasted words; every sentence contributes.
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 2 parameters and no output schema, the description provides the core function, an example, return statuses, and a behavioral guideline. It doesn't explain error handling or side effects like network calls, but the essential information for an agent to invoke it correctly is present.
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 baseline is 3. The description adds a concrete example for profile_url and mentions the return statuses, but does not add significant semantic details for the note parameter beyond what the schema already includes. It doesn't fully compensate for lack of output schema, but parameter-wise it's adequate.
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 'Send a LinkedIn connection request' with a specific action and resource. It distinguishes from sibling tools like socials_linkedin_profile or socials_linkedin_connection_status by focusing on the connection request action.
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 when to use this tool (to send a connection request) and provides an example input. It doesn't explicitly name alternatives but the purpose is clear enough that an agent can select it appropriately. It doesn't provide exclusions or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and discloses important behaviors: cross-window targeting, background default, and pin placement. It does not cover error handling or return value, but key side effects are well 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?
Three sentences, each earning its place: purpose, cross-window targeting, and focus/pin behavior. No filler or redundant repetition of schema details.
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 open-url tool, the description covers purpose, targeting, and pin behavior effectively. It lacks output/return value information and error scenarios, but those are not critical for this action.
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 detailed descriptions for url (including platform examples and encoding guidance) and focus (default false). The tool description itself adds no new parameter semantics beyond the schema, so 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?
Description opens with a specific verb+resource: 'Open a URL in a new tab and pin it as the Socials agent tab.' It clearly states the primary function and differentiates from sibling tools by noting automation targets this tab by ID across tabs and windows.
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?
Provides clear operational context: default is background, focus:true switches to it, and existing pins cause same-window opening to avoid stealing the workspace. However, it does not explicitly mention when to prefer this over alternatives like socials_navigate or socials_focus_agent_tab.
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 provided, the description carries the full burden. It implies a read-only operation and discloses the prerequisite, but it does not explicitly state that this is a safe, non-destructive read, nor does it mention potential error conditions or authentication requirements. The list of returned fields adds value but leaves some ambiguity (e.g., 'follow relationship').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences: the first states the action and prerequisite, the second enumerates the return fields. Every sentence earns its place, with no redundancy or filler.
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 zero-parameter read tool, the description covers the prerequisite, the extraction action, and all major returned fields. However, without an output schema, it could clarify the return format and the meaning of 'follow relationship' or error scenarios. It is complete for its simplicity but not exhaustive.
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 covers them all, so the baseline is 4. The description reinforces the only relevant context (the need to be on a profile URL) without needing to describe parameter syntax. This 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 uses a specific verb ('Extract') and clearly identifies the resource ('an X (Twitter) profile page'). It also lists the precise fields returned (name, handle, bio, etc.), which distinguishes it from sibling tools like socials_linkedin_profile or socials_get_page_content.
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 states an explicit prerequisite: 'Must navigate to a profile URL first.' This provides clear context on when the tool is usable. However, it does not exclude alternatives or explicitly say when not to use it, though the prerequisite implies that it should be used after navigating to a profile page.
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 provided, so the description carries the full burden. It discloses return format (MCP image content + JSON metadata), prerequisites (Socials Pro + extension), and URL restrictions (public URLs, cookie-gated issues). Lacks details on error handling or size limits but is generally transparent.
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?
Description is concise and front-loaded with the core purpose, followed by cost guidance, prerequisites, and limitations. All sentences earn their place, though slightly wordy in the requirements sentence.
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?
With one parameter and no output schema, the description compensates by explaining return format, cost implications, and limitations. It is fairly complete for a simple tool, but could mention error behavior or metadata specifics.
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%, so the baseline is 3. The description adds minor nuance about public vs cookie-gated URLs, but does not significantly enhance the parameter meaning beyond the schema description.
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 downloads an image by URL and returns it for visual inspection, with a specific verb and resource. It distinguishes from sibling tools by being the only one focused on image fetching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the agent when to use (only when visual inspection materially improves the answer) and when to avoid (prefer URLs/text metadata when sufficient). Also notes limitations like cookie-gated images needing another approach.
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 carries the full burden. It discloses the return metrics but does not explicitly state whether the operation is read-only, requires authentication, or has side effects. The name and description imply a safe diagnostic, but explicit safety details are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with the primary action, and contains no filler or redundant information. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless health check with no output schema, the description adequately covers the tool's purpose, return fields, and use case. It is complete for its simplicity and complexity level.
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 complete (100%). The description need not explain parameters, so the baseline score of 4 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 tool's purpose: checking connection health to the Socials extension and returning specific metrics (ping latency, consecutive failures, time since last successful ping). This distinguishes it from sibling tools like socials_diagnostics or socials_check_access, which likely focus on broader diagnostics or access validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides an explicit use case: 'detect if the extension has disconnected mid-session.' However, it does not mention alternatives or when not to use this tool, so it is slightly below a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful context such as the default mode ('top (default)'), time formats (YYYY-MM-DD vs Unix), and query syntax (#hashtags, @mentions, -exclusions). However, it omits details like return format, pagination, and authentication, so it falls short of full transparency.
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, well-structured paragraph with an opening summary sentence followed by a categorical breakdown. Every sentence provides useful information, and there is no redundant content. It is appropriately sized for the 22-parameter tool.
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 complex search tool with 22 parameters and no output schema, the description thoroughly covers input semantics, including modes, filters, and time handling. However, it lacks any mention of return format, pagination, or limitations, which would be needed for full completeness. The absence of output schema documentation is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already has 100% coverage, but the description adds significant value by grouping parameters into logical categories (User, Time, Engagement, Content, Location, Modes) and explaining how operators combine, e.g., 'since/until (YYYY-MM-DD) or since_time/until_time (Unix)'. It also elaborates query syntax beyond the schema's property descriptions.
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 'Advanced X search with full operator support,' identifying the tool as a comprehensive search tool for X. It distinguishes itself from sibling tools like socials_x_profile or socials_x_notifications by focusing on search capabilities and operator syntax, making its 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by detailing operator categories and query syntax, but it does not explicitly state when to use this tool over alternatives or when not to use it. No exclusions or comparisons with sibling search-related tools are provided, leaving usage guidance implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explicitly warns that actions are toggles and 'calling again may undo', which is a critical side-effect. It omits other potential details like auth/rate limits, but the key mutation behavior is transparently disclosed.
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?
Three short sentences, each adding essential information: the purpose, the data source, and the toggle caveat. No redundancy or filler; the structure is front-loaded and instantly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (3 parameters, no output schema) and the description covers purpose, usage, and the key toggle behavior. It could mention what happens after execution (e.g., return value or error handling), but given the tool's simplicity and full schema coverage, it is sufficiently complete for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and all parameters have descriptions. The description adds value by explaining that 'actions' are toggles and by directing that post_id should come from socials_get_feed, which enhances the meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Engage') and resource ('a tweet'), explicitly listing the supported actions: like, repost, bookmark, share. It clearly distinguishes from sibling tools by focusing on engagement with existing tweets, as opposed to creation (socials_create_post) or LinkedIn engagement (socials_linkedin_engage).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear when-to-use guidance: 'Pass post_id from socials_get_feed' ties usage to a concrete workflow, and 'Only use when the user explicitly wants these actions' sets an explicit condition. It does not name alternative tools for when-not cases, but the context is sufficient.
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 carries full responsibility. It states that the tool gets the focused tab, but it does not disclose what information is returned (e.g., title, URL, tab ID) or any potential side effects. It is not misleading, but lacks depth beyond the core action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main purpose and followed by a clear alternative reference. Every word contributes value, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description covers the essential context for selection and invocation: what it operates on and how it differs from a sibling. It stops short of describing the return value, which would be helpful but not critical for such a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no parameter meaning to add. The baseline for zero-param tools is 4, and the description does not need to clarify any parameter semantics as none exist.
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 verb 'Get' and the resource 'currently focused browser tab', with an explanatory parenthetical 'what you are looking at'. It further distinguishes itself from the sibling tool by naming socials_get_agent_tab, making its 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly provides usage context: use this tool for the currently focused tab, and for the tab Claude automates, use socials_get_agent_tab. This is direct guidance on when to use this tool versus an alternative, meeting the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by disclosing the internal action sequence: 'Opens Create New Post dialog, uploads the image(s), fills caption and hashtags, then posts.' It also notes the prerequisite and confirmation requirement, adding behavioral context beyond just the purpose. It stops short of explaining failure modes or post-verification steps, but for a posting tool it is quite 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?
Four concise sentences, each serving a distinct purpose: purpose/constraint, prerequisite, parameter usage, and safety confirmation. No wasted words, front-loaded with the core action. The structure is easy to parse and remember.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, prerequisite, parameter semantics, and the user-confirmation requirement, which is substantial for a tool with no annotations and no output schema. It lacks explicit guidance on what happens after posting (e.g., verifying success), but the provided context is sufficient for an agent to invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds value by explicitly explaining the distinction: 'Use image_path for a single image or image_paths array for a carousel.' This helps the agent choose correctly between the two path parameters, which is not entirely clear from the schema alone. The confirmation requirement also contextualizes the parameters in workflow.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Post a photo or carousel (up to 10 images) to Instagram.' This clearly distinguishes it from sibling tools like socials_create_post and other platform-specific tools. The scope is explicit and leaves no ambiguity about 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a clear prerequisite ('The agent tab must be on instagram.com') and instructs to confirm with the user before calling. It also explains when to use image_path vs image_paths. However, it does not explicitly contrast with sibling tools like socials_create_post, though the name and Instagram-specific context make the intended use obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the effect (brings to foreground) and the analogy to clicking, which is the entire behavioral scope. It does not mention potential side effects like requiring the tab to be pinned, but for this simple action the description 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 two short sentences: the first states the action, the second gives the use case. Every word earns its place, and the key information is front-loaded. There is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema, and a straightforward UI action—the description fully covers what the tool does and when to use it. The sibling list shows related tools, but no additional context is needed here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema is empty. According to the rubric, a baseline of 4 applies for 0-parameter tools because no parameter explanation is needed. The description confirms no inputs are required.
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 and resource: 'Bring the pinned agent tab to the foreground', which clearly states the action and target. It also adds an analogy 'same as clicking it' to reinforce understanding. This distinguishes it from sibling tools like socials_set_agent_tab (configuration) and socials_get_agent_tab (retrieval).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Use when you want to watch what Claude is doing.' This provides clear context. While it does not name alternatives or exclusions, the specific use case is enough for a zero-parameter UI action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It adds the key edge-case behavior ('Returns false if already on the last page'), which is valuable. It does not mention side effects like browser state changes, but for a simple pagination action, this is adequate.
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?
Two short sentences: the first states the action, the second states the return behavior. No unnecessary words or repetition; the description is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and a simple navigation action, the description provides complete context: what it does and what happens at the boundary condition. No further details are needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4 as per the rubric. The description appropriately does not attempt to document parameters that do not exist.
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 ('Go to') with a clear resource ('the next page of LinkedIn search results'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like socials_navigate or socials_scroll by targeting LinkedIn search pagination specifically.
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 clearly indicates the tool is for advancing through LinkedIn search results pages. It does not explicitly mention when not to use it or alternatives (e.g., socials_linkedin_go_to_page), but the context is straightforward enough that the usage is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the UI workflow (opens reply UI, fills text, submits), a platform limitation (YouTube: no media attachments), and a required user confirmation step. This is comprehensive behavioral disclosure for a tool of this type.
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 information-dense yet structured clearly with bold platform labels and a bullet-like semicolon list. Every sentence adds value—platform-specific IDs, workflow, media constraint, and a safety reminder—without redundancy or unnecessary prose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a posting action with no output schema, the description covers all essential aspects: what it does, how to derive required IDs per platform, a platform-specific limitation, and a mandatory user-confirmation step. This is sufficient for an agent to invoke the tool correctly in the intended 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 description coverage is 100% and the post_id parameter description already includes the platform-specific instructions. The tool description repeats this information and adds only marginal context like the pinned-tab scope and YouTube media restriction, which doesn't significantly enrich parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Post a reply in the pinned agent tab' and then breaks down the expected post_id format per platform (X, LinkedIn, YouTube). This makes the tool's purpose unmistakable and distinguishes it from broader tools like socials_engage_post or socials_create_post.
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 gives explicit source guidance for post_id on each platform (from socials_get_feed, socials_get_page_content) and adds a hard rule to confirm text with the user before posting. It does not explicitly name alternative tools to use instead, but the platform-specific instructions effectively define the appropriate usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It reveals important behaviors: 'Uses device-based auth if device was previously registered (works even when logged out)' and 'Auto-registers device for future sessions if user is logged in.' This goes beyond a simple 'refresh' and explains side effects. However, it doesn't mention potential impacts like invalidating existing sessions or what success/failure look like, but the core behaviors are covered.
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 three concise sentences, front-loaded with 'RECOVERY STEP 1' for immediate context. Each sentence earns its place: purpose, behavior, and fallback. There is no fluff or redundancy, making it highly efficient.
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 zero-parameter recovery tool with no output schema, the description is nearly complete. It provides purpose, conditions, behavior, and a fallback action. Missing is an explicit statement of what constitutes success or failure, but the agent can infer this from the tool's role in a recovery sequence, and sibling tools like diagnostics can verify the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameters, and it doesn't. It effectively uses no input schema, and the description adds context about behavior rather than parameter details, which is appropriate for a no-parameter tool.
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 action: 'Restore authentication when connected but auth fails.' It also distinguishes itself from sibling tools by labeling itself as 'RECOVERY STEP 1' and explicitly referencing a fallback step (socials_restart_bridge). This makes the tool's purpose unambiguous and distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'when connected but auth fails.' It also gives a clear fallback path: 'If this fails, proceed to socials_restart_bridge (step 2).' This tells the agent exactly when to invoke this tool and what to do next, which is ideal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It transparently discloses that the tool returns null when no tab is set and instructs to call socials_open_tab in that case. However, it does not mention any potential errors or side effects, though as a getter these are unlikely.
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, well-structured sentence that front-loads the main action and includes important conditional guidance. Every phrase earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains the return value (URL, title, platform, null) and the follow-up action. It also provides enough context to distinguish from sibling tools like socials_set_agent_tab and socials_open_tab, making it complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining the return values and null semantics, which complements the empty schema. No parameter details are needed.
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 verb 'Get' and the specific resource 'pinned Socials agent tab', and enumerates the return fields (URL, title, platform) including possible values. It distinguishes itself from sibling tools like socials_get_active_tab by specifying 'pinned agent tab'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: it should be called to retrieve the pinned agent tab, and if the result is null, the agent should call socials_open_tab. This directly addresses usage context and provides an alternative action.
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. It discloses the destructive action 'Kills stale processes on port 9847' and states it 'restarts WS server.' It also mentions a required user action afterward. While it does not describe side effects on active connections or failure modes, the key behavioral aspects are transparent for a recovery 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 compact, front-loaded with the recovery step identifier, and every sentence serves a purpose: triggering condition, action taken, and post-requisite. No fluff or redundant phrasing. The 'AFTER THIS' section is a clear structured step.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema, no annotations), the description is fully complete. It covers what the tool does, when to use it, what side effects occur (process kill, restart), and what the user should do next. There is no ambiguity about how to invoke or follow up.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing to explain beyond the empty schema. The description adds context about the tool's purpose but no parameter-specific information is needed. Per rubric baseline for 0 params is 4, and the description does not need to compensate for any schema gaps.
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 action: 'Restart the WebSocket bridge.' It specifies the resource (WebSocket bridge) and the conditions ('when refresh_auth fails or connection is stuck'), distinguishing it from sibling tools like socials_check_access which only checks status. This is a specific verb+resource+scope definition.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use when socials_check_access shows ws_server_listening=false or connected=false.' It also provides a clear after-step ('User must refresh Socials extension in browser, then retry socials_check_access'), giving the user a sequential recovery workflow. This goes beyond basic guidance by naming the triggering condition and follow-up.
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:

[![socials MCP server](https://glama.ai/mcp/servers/Brainrot-Creations/socials/badges/card.svg)](https://glama.ai/mcp/servers/Brainrot-Creations/socials)

Score Badge

Copy to your README.md:

[![socials MCP server](https://glama.ai/mcp/servers/Brainrot-Creations/socials/badges/score.svg)](https://glama.ai/mcp/servers/Brainrot-Creations/socials)

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/Brainrot-Creations/socials'

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