Li Data Scraper MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is significant overlap between tools targeting similar resources, such as get_profile_post_and_comments, get_profile_post_comment, and get_profiles_comments, which could confuse an agent about which to use for profile comments. However, descriptions help differentiate some tools, like distinguishing company vs. profile operations, preventing complete ambiguity.
Naming Consistency2/5
Naming is inconsistent with mixed patterns: most tools use get_* or search_* prefixes, but about_the_profile deviates, and some names are overly verbose or include escaped characters (e.g., get_profile_data_and_connection_u0026_follower_count). This lack of a uniform convention reduces predictability and readability.
Tool Count3/5
With 20 tools, the count is borderline high for a data scraper server, feeling slightly heavy but not extreme. It covers multiple domains (profiles, companies, posts, searches), which justifies some volume, but could benefit from consolidation to avoid overlap and improve coherence.
Completeness4/5
The tool set provides broad coverage for LinkedIn data scraping, including profile, company, post, comment, reaction, and search operations, with minor gaps such as missing update or delete tools (expected for read-only scraping) and no direct tool for managing credits or errors. Overall, it supports core workflows without major dead ends.
Average 2.7/5 across 20 of 20 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it offers no information about what the tool does, its effects, permissions, rate limits, or any other behavioral traits, making it completely opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While 'Ping' is extremely brief, this is under-specification rather than effective conciseness. The single word fails to convey necessary information, making it inefficient and unhelpful rather than appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is completely inadequate. It provides no information about the tool's function, behavior, or output, failing to compensate for the missing structured data.
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 schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but this is appropriate given the lack of parameters, warranting a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
Tautological: description restates name/title.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context, prerequisites, or exclusions, leaving the agent with no information about appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. 'Search Post by Hashtag' implies a read-only search operation but reveals nothing about authentication requirements, rate limits, result format, pagination, error conditions, or whether it searches across all posts or specific sources. For a search tool with zero annotation coverage, this represents minimal behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While technically concise with just three words, this represents under-specification rather than effective brevity. The description fails to provide necessary context about what's being searched, how results are returned, or when to use this versus alternatives. Every word should earn its place, but here the minimal content leaves critical questions unanswered.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent purpose (searching posts by hashtag), no annotations, no output schema, and multiple similar sibling tools, the description is severely incomplete. It doesn't explain what constitutes a 'post', what data sources are searched, what authentication might be required, how results are structured, or how this differs from other search/retrieval tools. This minimal description fails to provide adequate context for effective tool 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?
The tool has zero parameters with 100% schema description coverage, so the schema fully documents the absence of parameters. The description doesn't need to compensate for parameter documentation gaps. While it mentions 'hashtag' which might imply a parameter, the actual schema shows no parameters, so the description adds no parameter semantics beyond what's already clear from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Post by Hashtag' is a tautology that essentially restates the tool name without adding meaningful clarification. While it indicates the tool searches posts using hashtags, it lacks specificity about what 'post' refers to (e.g., social media posts, blog posts) and doesn't distinguish it from sibling tools like 'search_post_by_keyword' or 'get_profiles_posts'. This minimal expansion beyond the name provides only basic purpose indication.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for hashtag-based searches, or differentiate from similar tools like 'search_post_by_keyword' (keyword-based) or 'get_profiles_posts' (profile-specific). With multiple sibling search/retrieval tools available, this complete lack of usage guidance is inadequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. It doesn't indicate whether this is a read-only operation, what permissions might be required, how results are returned (e.g., pagination, format), or any rate limits. The vague 'Get' verb offers no insight into the tool's behavior beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get post comment Reaction') but suffers from under-specification rather than efficient communication. While it's front-loaded with the core action, it lacks necessary detail to be truly helpful. The single sentence structure is simple but incomplete for a tool that likely requires more context to use effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's apparent complexity (inferred from sibling tools dealing with reactions, posts, and comments) and the absence of both annotations and an output schema, the description is inadequate. It doesn't explain what the tool returns, how to interpret results, or any behavioral aspects. For a tool that likely interacts with social media data structures, this minimal description leaves critical gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters need documentation. The description appropriately doesn't attempt to explain nonexistent parameters, which aligns with the schema's completeness. This meets the baseline expectation for tools without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get post comment Reaction' is a tautology that essentially restates the tool name without adding meaningful clarification. It doesn't specify what kind of reaction is retrieved (e.g., likes, emojis, counts) or whether this is for a specific comment or all comments. While it mentions the resource (post comment reaction), the verb 'Get' is too generic compared to more specific alternatives like 'Retrieve' or 'Fetch' that might better indicate read-only behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a specific post or comment ID), differentiate from sibling tools like 'get_post_reactions' or 'get_profile_reactions', or indicate any contextual constraints. This leaves the agent without direction on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. However, it only states what the tool does without any information on traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. For a tool with zero annotation coverage, this is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase that is concise but under-specified. While it avoids unnecessary words, it fails to provide essential details that would help an agent understand the tool's purpose and usage. This brevity comes at the cost of clarity, making it inefficient in conveying needed information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by the tool name (involving profile data, connections, and followers), the description is incomplete. There are no annotations, no output schema, and the description lacks details on behavioral traits, usage context, or differentiation from siblings. This leaves significant gaps for an agent to effectively use the tool.
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 0 parameters, and the schema description coverage is 100%, meaning there are no parameters to document. The description does not need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description does not mislead about parameters, and the schema fully covers the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Profile Data and Connection & Follower Count' is essentially a tautology that restates the tool name with minimal elaboration. It specifies the verb 'Get' and resources 'Profile Data' and 'Connection & Follower Count', but lacks specificity about what profile data includes or how it distinguishes from siblings like 'get_public_profile_data_by_url' or 'get_profile_recent_activity_time'. This is vague and does not clearly differentiate from alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are multiple sibling tools related to profiles (e.g., 'get_public_profile_data_by_url', 'get_profile_recent_activity_time'), but the description does not mention any context, prerequisites, or exclusions for usage. This leaves the agent without direction on selecting the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Search Post by Keyword' implies a read-only query operation, but it doesn't specify whether it returns all matching posts, is paginated, has rate limits, requires authentication, or what the output format is. For a tool with zero annotation coverage, this is a significant gap 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just three words, but this brevity leads to under-specification rather than efficiency. It's front-loaded but lacks necessary detail. While it avoids waste, it fails to provide essential context, making it minimally adequate but not helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns (e.g., list of posts, metadata), how results are structured, or any behavioral aspects like error handling. For a search tool with no structured data support, this leaves critical gaps for an AI agent to understand its operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description mentions 'keyword' which might imply a parameter, but since the schema explicitly defines no parameters, this doesn't add value or cause confusion. With zero parameters, the baseline is 4 as no parameter semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Post by Keyword' is a tautology that essentially restates the tool name without adding meaningful context. It specifies the verb 'search' and resource 'post' with a 'keyword' qualifier, but lacks specificity about what type of posts (e.g., social media, blog, forum) or how the search operates. It doesn't distinguish from siblings like 'search_post_by_hashtag' or 'get_profiles_posts' beyond the keyword aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose it over 'search_post_by_hashtag' for keyword-based searches versus hashtag-based ones, or when to use it instead of 'get_profiles_posts' for retrieving posts. There's no context about prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the tool returns data, implying a read-only operation, but lacks details on permissions, rate limits, error handling, or what 'enrich' entails. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence, but it is under-specified rather than efficiently informative. It lacks front-loaded critical details, such as what 'enrich' means or how it differs from siblings, making it less helpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of sibling tools and the lack of annotations and output schema, the description is incomplete. It fails to explain what 'enrich' entails, how results are structured, or when to use this over other company-related tools, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description does not add parameter information, but this is acceptable as there are no parameters to explain, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'returns enrich company details' is vague and tautological—it essentially restates the tool name 'get_company_details' with slightly different wording. It lacks a specific verb and resource, and does not differentiate from siblings like 'get_company_by_domain' or 'get_public_profile_data_by_url'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention context, prerequisites, or exclusions, leaving the agent with no information on how to choose between this and sibling tools like 'get_company_by_domain'.
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. 'Get company jobs' implies a read operation, but it doesn't specify whether this requires authentication, what format the jobs data is returned in, if there are rate limits, or any other behavioral traits. The description is minimal and fails to provide necessary operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise ('Get company jobs'), but this brevity borders on under-specification rather than effective conciseness. While it's front-loaded and wastes no words, it lacks the detail needed to be genuinely helpful, making it more sparse than optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema), the description is incomplete. It doesn't explain what 'company jobs' entails, how results are returned, or any usage context. Without annotations or output schema, the description should provide more operational detail to compensate, but it fails to do so.
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 0 parameters with 100% schema description coverage, so no parameter documentation is needed. The description doesn't mention parameters, which is appropriate given the empty input schema. This meets the baseline expectation for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get company jobs' is a tautology that essentially restates the tool name. It specifies the verb 'get' and resource 'company jobs', but provides no additional context about what 'company jobs' refers to or distinguishes it from sibling tools like 'get_company_details' or 'get_company_by_domain'. The purpose is vague and lacks specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description offers no context about prerequisites, when this tool is appropriate, or how it differs from sibling tools that also retrieve company-related information. This leaves the agent with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Enrich public profile data' implies a read-only operation that might fetch or augment data, but it doesn't specify behavioral traits such as whether it requires authentication, has rate limits, what data sources it uses, or what the output format might be. The description is too vague to adequately inform the agent about how the tool behaves beyond a basic read intent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single phrase 'Enrich public profile data', which is concise but under-specified. It lacks structure such as front-loading key details or elaboration that could add clarity. While it avoids unnecessary words, it fails to provide enough context to be truly helpful, making it more sparse than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity implied by 'enrich' (which suggests data augmentation) and the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'enrich' entails, what data is returned, or any behavioral constraints. For a tool with no structured support, the description should provide more context to guide the agent effectively, but it falls short.
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 0 parameters, and the schema description coverage is 100% (though trivial since there are no parameters). The description doesn't need to add parameter semantics, as there are none to document. A baseline score of 4 is appropriate because the description doesn't have to compensate for any parameter gaps, and it aligns with the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Enrich public profile data' is vague about the specific action and resource. It mentions 'public profile data' but doesn't specify what 'enrich' means operationally (e.g., fetch, augment, or retrieve). While it distinguishes from some siblings like 'ping' or 'search_people', it doesn't clearly differentiate from similar tools like 'get_profile_data_and_connection_u0026_follower_count' or 'get_profile_recent_activity_time', leaving the purpose ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention any context, prerequisites, or exclusions for usage. Given siblings like 'get_profile_data_and_connection_u0026_follower_count' that might overlap in functionality, the lack of explicit or implied usage guidelines makes it unclear when this tool is the appropriate choice.
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 discloses a key behavioral trait: that results may be limited due to non-public profiles being filtered out. However, it lacks details on other aspects like rate limits, authentication needs, or error handling, making it only partially informative.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, but it is not front-loaded with the tool's purpose. The first sentence addresses a limitation rather than the core function, which reduces clarity, though it avoids unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a search function with no parameters but behavioral nuances) and lack of annotations and output schema, the description is incomplete. It mentions result filtering but omits essential details like what the search criteria are, how results are returned, or error conditions, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter information, which is appropriate here, and it compensates by providing context about result filtering, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description fails to state what the tool actually does—it only describes a limitation of the results. It mentions 'search_people' in the tool name, but the description does not specify the action (e.g., searching for people by criteria) or the resource involved, making it vague and tautological by not elaborating beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or comparisons with sibling tools like 'get_public_profile_data_by_url' or 'get_profile_data_and_connection_u0026_follower_count', leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read operation but doesn't disclose behavioral traits like authentication needs, rate limits, error conditions, or what happens if no post exists. This leaves significant gaps for an agent to use it correctly.
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, efficient sentence with no wasted words. It's front-loaded with the core action, making it easy to scan and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and multiple sibling tools, the description is incomplete. It doesn't explain what data is returned, how to identify the target profile/post, or handle edge cases, making it inadequate for reliable agent 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is acceptable here, but it could hint at implicit inputs (e.g., profile identifier), keeping it from a perfect score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves a profile post and its comments, which is a clear purpose. However, it's vague about what specific profile or post is targeted, and it doesn't distinguish from siblings like 'get_profile_post_comment' or 'get_profiles_posts', which handle similar data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With siblings like 'get_profile_post_comment' (singular comment) and 'get_profiles_posts' (multiple posts), the description lacks context for selection, such as whether this tool fetches a specific post or all posts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '1 credit per call', indicating a cost or rate limit, which is useful. However, it lacks details on permissions, data freshness, error handling, or return format, leaving significant gaps for a tool that fetches data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with two short sentences that convey key information: the action and a cost note. It's front-loaded and wastes no words, though it could be slightly more structured by explicitly stating the tool's scope or limitations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (fetching company posts) and lack of annotations and output schema, the description is incomplete. It doesn't explain what 'posts' entail, the data format returned, or any prerequisites, making it inadequate for an agent to use effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, but this is acceptable given the schema's completeness. A baseline of 4 is applied as it adequately handles the lack of parameters without introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('last 50 posts of a company'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_profiles_posts' or 'get_profile_post_and_comments', which might have overlapping functionality, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, such as 'get_profiles_posts' or 'search_post_by_keyword'. It mentions '1 credit per call', which hints at cost but doesn't inform usage context or exclusions, leaving the agent without clear direction on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states a read operation ('Get'), implying it's likely non-destructive, but doesn't disclose any behavioral traits such as authentication needs, rate limits, pagination, or what happens if the post doesn't exist. This leaves significant gaps for an agent to use it correctly.
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, efficient sentence with no wasted words. It's front-loaded with the core purpose, making it easy to parse quickly. Every word contributes directly to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what the return values are (e.g., comment list format, error handling) or provide enough context for safe usage. For a tool with no structured safety hints, this minimal description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description doesn't mention any parameters, which is appropriate here as it implies the tool might operate without inputs or use default/contextual values. This aligns with the schema, so it earns a baseline score of 4 for not introducing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('comments of a company post'), making the purpose understandable. However, it doesn't differentiate from sibling tools like 'get_profile_post_and_comments' or 'get_profiles_comments', which appear to retrieve similar comment data but for different entities (profile vs company).
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. With sibling tools like 'get_profile_post_and_comments' and 'get_companys_post', it's unclear when this specific tool is appropriate, and there are no prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving '50 comments' (implying a limit or default behavior) and specifies 'profile post (activity)', but fails to address critical aspects like rate limits, authentication needs, error handling, or whether it's read-only. This leaves significant gaps in understanding the tool's 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 a single, efficient sentence that directly states the tool's function without any fluff or repetition. It is front-loaded with the core action and resource, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of fetching comments (which may involve pagination, sorting, or filtering) and the lack of annotations and output schema, the description is insufficient. It doesn't explain return values, error cases, or behavioral constraints, leaving the agent with incomplete context for effective 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?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining focus on the tool's purpose without redundancy. A baseline of 4 is applied since no parameters exist, and the description doesn't attempt to compensate unnecessarily.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('50 comments of a profile post (activity)'), making the purpose understandable. However, it doesn't explicitly differentiate from siblings like 'get_profile_post_and_comments' or 'get_profiles_comments', which might offer overlapping functionality, preventing a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_profile_post_and_comments' or 'get_profiles_comments'. The description lacks context about prerequisites, exclusions, or specific scenarios, leaving the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. The description only states the tool's purpose without revealing any behavioral traits such as whether it requires authentication, has rate limits, returns paginated results, or what format the output takes. For a tool with zero annotation coverage, this lack of detail is inadequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence: 'Find out what posts a profile reacted to.' It is front-loaded with the core purpose, has no unnecessary words, and efficiently communicates the tool's function without any waste. This makes it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is incomplete. It only states the tool's purpose without addressing behavioral aspects like authentication needs, rate limits, or output format. For a tool with no structured data to rely on, the description should provide more context to be fully helpful to an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, meaning no parameters are documented in the schema. The description does not add any parameter information, which is appropriate since there are no parameters to describe. According to the rules, for 0 parameters, the baseline score is 4, as the description does not need to compensate for missing schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find out what posts a profile reacted to.' It specifies the action ('find out') and the target resource ('posts a profile reacted to'), making it easy to understand what the tool does. However, it does not explicitly differentiate itself from sibling tools like 'get_post_reactions' or 'get_profile_recent_activity_time,' which might have overlapping or related functionalities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, context for usage, or exclusions. Given the presence of sibling tools such as 'get_post_reactions' and 'get_profile_recent_activity_time,' which could potentially serve similar purposes, the lack of differentiation or explicit usage instructions is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, it doesn't specify authentication requirements, rate limits, error conditions, or what happens if the profile doesn't exist. For a tool with zero annotation coverage, this leaves critical behavioral traits undocumented.
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, efficient sentence that front-loads the key action ('Get') and lists the specific data points to be retrieved. There is no wasted verbiage, repetition, or unnecessary elaboration, making it highly concise and well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (simple read operation with no parameters) and the absence of annotations and output schema, the description is minimally adequate. It specifies what data will be retrieved but doesn't cover behavioral aspects like authentication or error handling. For a tool with no structured output documentation, it could benefit from more detail on return format or data structure.
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 0 parameters with 100% schema description coverage, so the schema fully documents the input requirements. The description doesn't need to add parameter information, and it appropriately focuses on the output semantics (what data will be retrieved). This meets the baseline expectation for tools with no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('Get') and resources ('profile verification details', 'profile's joined', 'contact information updated', 'profile photo updated date'), making it easy to understand what information will be retrieved. However, it doesn't explicitly differentiate from sibling tools like 'get_profile_data_and_connection_u0026_follower_count' or 'get_public_profile_data_by_url', which might also retrieve profile-related data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage based on the purpose alone. With many sibling tools that might overlap in functionality (e.g., 'get_profile_data_and_connection_u0026_follower_count'), this lack of differentiation is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states a read operation ('Get'), implying it's likely safe, but doesn't cover aspects like rate limits, authentication needs, pagination, or return format. This leaves significant gaps in understanding how the tool behaves beyond its basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no wasted words. It's front-loaded and efficiently conveys the core purpose without unnecessary elaboration, making it highly concise and well-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?
Given the tool has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on behavior, output, or usage context, making it incomplete for full agent understanding despite the low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate here, but since there are no params, it doesn't compensate for any gaps, aligning with the baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('profiles that reacted to the post'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_profile_reactions' or 'get_post_comment_reaction', which appear related to reactions on different entities, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states it's a read operation ('Get'), implying no mutation, but doesn't cover aspects like authentication needs, rate limits, error conditions, or what 'last activity' entails (e.g., time format, scope). This leaves significant gaps for a tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys the core function without any wasted words. It's front-loaded with the main action and resource, making it easy to parse and understand quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It states what the tool does but lacks details on behavior, output format, or usage context. For a read-only tool with no parameters, this is the bare minimum, leaving room for improvement in transparency and guidelines.
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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description doesn't add parameter semantics, but with no parameters, this is acceptable; it avoids redundancy and maintains focus on the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('the profile's last activity time'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from siblings like 'get_profile_data_and_connection_&_follower_count' or 'get_public_profile_data_by_url', which might also provide activity-related data, so it misses full sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'get_profile_data_and_connection_&_follower_count' that might include activity time, there's no indication of trade-offs, prerequisites, or specific contexts for choosing this tool, leaving usage ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '1 credit per call', which adds useful context about cost or rate limits, but fails to describe other critical behaviors like response format, pagination (since it specifies 'last 50'), error handling, or authentication needs. This leaves significant gaps in understanding how the tool operates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of just two short sentences that directly state the tool's function and a key operational detail ('1 credit per call'). Every word earns its place, with no wasted information, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and a cost hint, but lacks details on output structure, error cases, or how 'last 50' is determined (e.g., sorting or time range). For a tool with no structured data to rely on, this leaves the agent with incomplete contextual understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so the schema fully documents the absence of parameters. The description does not add parameter-specific information, which is appropriate here. Since there are no parameters, the baseline is 4, as 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('last 50 comments of a profile'), making the purpose specific and understandable. However, it does not explicitly distinguish this tool from sibling tools like 'get_profile_post_and_comments' or 'get_profile_post_comment', which might handle similar comment-related queries, so it misses 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 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 sibling tools that might retrieve comments in different contexts (e.g., by post or with filtering). It mentions '1 credit per call', which hints at cost but does not define usage scenarios or exclusions, leaving the agent without clear contextual direction.
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 adds some context: the credit cost implies a rate limit or billing consideration, and 'enrich' suggests it fetches external data. However, it lacks details on permissions, error handling, response format, or whether it's read-only or mutative, leaving significant gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: a single sentence that states the purpose and includes a critical behavioral note (credit cost). Every word earns its place, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the core purpose and a cost implication, but lacks details on return values, error cases, or integration context. For a data enrichment tool, more information on what 'enrich' entails would be helpful, though the absence of an output schema increases the burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description implies the domain is the key input ('by domain'), but since there are no parameters, this is acceptable. Baseline is 4 for 0 parameters, as the description doesn't 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Enrich company data by domain' specifies both the verb ('enrich') and resource ('company data'), with the domain serving as the key input. However, it doesn't explicitly differentiate from siblings like 'get_company_details' or 'get_public_profile_data_by_url', which might offer overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. While it mentions '1 credit per successful request,' this is a cost implication rather than usage context. There's no mention of prerequisites, when-not-to-use scenarios, or comparisons to sibling tools like 'get_company_details' or 'search_people'.
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 a behavioral trait ('1 credit per call'), which is useful for cost awareness. However, it lacks details on other aspects such as rate limits, error handling, or response format, making it incomplete for a tool with no annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences that directly state the tool's function and cost implication. Every word serves a purpose, and it is front-loaded with the core action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is adequate but minimal. It covers the basic purpose and cost, but for a data retrieval tool, it could benefit from mentioning response structure or limitations (e.g., post format, time range). Without output schema, some context on return values would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details, which is appropriate here, but it could have mentioned implicit assumptions (e.g., profile identification method). Given the baseline of 4 for 0 parameters, this is scored accordingly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and resource ('last 50 posts of a profile'), making the purpose specific and understandable. However, it doesn't explicitly distinguish this tool from similar siblings like 'get_profile_post_and_comments' or 'get_profile_recent_activity_time', which might also retrieve profile-related posts or activities, leaving some ambiguity in differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With multiple sibling tools that might overlap (e.g., 'get_profile_post_and_comments', 'get_profile_recent_activity_time'), there is no indication of context, prerequisites, or exclusions, leaving the agent to infer usage based on tool names alone.
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:

[![bachai-li-data-scraper MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-li-data-scraper/badges/card.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-li-data-scraper)

Score Badge

Copy to your README.md:

[![bachai-li-data-scraper MCP server](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-li-data-scraper/badges/score.svg)](https://glama.ai/mcp/servers/BACH-AI-Tools/bachai-li-data-scraper)

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/BACH-AI-Tools/bachai-li-data-scraper'

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