Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@LinkedIn Data API MCP Server get profile data and recommendations for ryanroslansky"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
用于访问 Linkedin Data Api API 的 MCP 服务器。
EMCP 是一个强大的 MCP 服务器管理平台，让您无需手动配置即可快速使用各种 MCP 服务器！
🌐 访问 EMCP 平台
📝 注册并登录账号
🎯 进入 MCP 广场，浏览所有可用的 MCP 服务器
🔍 搜索或找到本服务器（bach-linkedin_data_api）
🎉 点击 "安装 MCP" 按钮
✅ 完成！即可在您的应用中使用
✨ 零配置：无需手动编辑配置文件
🎨 可视化管理：图形界面轻松管理所有 MCP 服务器
🔐 安全可靠：统一管理 API 密钥和认证信息
🚀 一键安装：MCP 广场提供丰富的服务器选择
📊 使用统计：实时查看服务调用情况
立即访问 EMCP 平台 开始您的 MCP 之旅！
Related MCP server: LinkedIn MCP Server
这是一个 MCP 服务器，用于访问 Linkedin Data Api API。
PyPI 包名: bach-linkedin_data_api
版本: 1.0.0
传输协议: stdio
pip install bach-linkedin_data_apipip install -e .# 运行（uvx 会自动安装并运行）
uvx --from bach-linkedin_data_api bach_linkedin_data_api
# 或指定版本
uvx --from bach-linkedin_data_api@latest bach_linkedin_data_apipython server.py# 安装
pip install bach-linkedin_data_api
# 运行（命令名使用下划线）
bach_linkedin_data_api此 API 需要认证。请设置环境变量:
export API_KEY="your_api_key_here"变量名 | 说明 | 必需 |
| API 密钥 | 是 |
| 不适用 | 否 |
| 不适用 | 否 |
编辑 Cursor MCP 配置文件 ~/.cursor/mcp.json:
{
"mcpServers": {
"bach-linkedin_data_api": {
"command": "uvx",
"args": ["--from", "bach-linkedin_data_api", "bach_linkedin_data_api"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}编辑 Claude Desktop 配置文件 claude_desktop_config.json:
{
"mcpServers": {
"bach-linkedin_data_api": {
"command": "uvx",
"args": ["--from", "bach-linkedin_data_api", "bach_linkedin_data_api"],
"env": {
"API_KEY": "your_api_key_here"
}
}
}
}此服务器提供以下工具:
get_company_by_domainEnrich the company data by domain. 1 credit per successful request.
端点: GET /get-company-by-domain
参数:
domain (string) 必需: Example value: apple.com
get_company_details_by_idThe endpoint enrich full details of the company
端点: GET /get-company-details-by-id
参数:
id (string) 必需: Example value: 1441
get_company_detailsThe endpoint enrich full details of the company
端点: GET /get-company-details
参数:
username (string) 必需: Example value: google
get_profile_school_interestsGet the profile's school interests up to 50 results per page
端点: POST /profiles/interests/schools
get_profile_newsletter_interestsGet the profile's newsletter interests up to 50 results per page
端点: POST /profiles/interests/newsletters
get_similar_profilesReturns profiles that are similar to the provided profile
端点: GET /similar-profiles
参数:
url (string) 必需: Example value: https://www.linkedin.com/in/williamhgates/
get_profile_positions_with_skillsGet Profile Positions With Skills
端点: GET /profiles/position-skills
参数:
username (string) 必需: Example value: tedgaubert
get_profile_company_interestGet the profile's company interests up to 50 results per page.
端点: POST /profiles/interests/companies
profile_data_u0026_recommendationsGet Profile Data, Given and Received Recommendations. 2 credits per call
端点: GET /all-profile-data
参数:
username (string) 必需: Example value: ryanroslansky
get_given_recommendationsTo scrape all recommendations from a profile, increase the start value to +100 for each request until you reach the total recommendations count. You can find the total recommendations count in the response
端点: GET /get-given-recommendations
参数:
username (string) 必需: Example value: ryanroslansky
start (string): Example value: 0
get_profile_data_connection_u0026_follower_count_and_postsGet Profile Data, Connection \u0026 Follower Count and Posts. 2 credits per call
端点: GET /profile-data-connection-count-posts
参数:
username (string) 必需: Example value: adamselipsky
about_the_profileGet profile verification details, profile’s joined, contact information updated, and profile photo updated date
端点: GET /about-this-profile
参数:
username (string) 必需: Example value: williamhgates
get_profile_data_and_connection_u0026_follower_countGet Profile Data and Connection \u0026 Follower Count
端点: GET /data-connection-count
参数:
username (string) 必需: Example value: adamselipsky
get_received_recommendationsTo scrape all recommendations from a profile, increase the start value to +100 for each request until you reach the total recommendations count. You can find the total recommendations count in the response
端点: GET /get-received-recommendations
参数:
username (string) 必需: Example value: ryanroslansky
start (string): Example value: 0
get_profiles_commentsGet last 50 comments of a profile. 1 credit per call
端点: GET /get-profile-comments
参数:
username (string) 必需: Example value: williamhgates
get_profile_reactionsFind out what posts a profile reacted to
端点: GET /get-profile-likes
参数:
username (string) 必需: Example value: adamselipsky
start (string): for pagination, increase +100 to parse next result until you see less than 100 results. it could be one of these; 0, 100, 200, 300, 400, etc.
paginationToken (string): It is required when fetching the next results page. The token from the previous call must be used.
get_profile_post_and_commentsGet profile post and comments of the post
端点: GET /get-profile-post-and-comments
参数:
urn (string) 必需: URN value of the post. Example URL: https://www.linkedin.com/posts/andy-jassy-8b1615_amazon-bedrock-customers-have-more-choice-activity-7181285160586211328-Idxl/?utm_source=share&utm_medium=member_desktop Example URN: 7181285160586211328
get_profile_connection_u0026_follower_countGet Profile Connection \u0026 Follower Count
端点: GET /connection-count
参数:
username (string) 必需: Example value: adamselipsky
get_profile_post_commentGet 50 comments of a profile post (activity)
端点: GET /get-profile-posts-comments
参数:
urn (string) 必需: Post urn value
sort (string) 必需: it could be one of these; mostRelevant, mostRecent
page (string): Example value: 1
paginationToken (string): It is required when fetching the next results page. The token from the previous call must be used.
search_people_by_urlSearch profiles by a keyword. You may see less than 10 results per page. This is because not return all profiles as public, sometimes hiding profiles and these profiles appear in the result. The endpoint automatically filters these profiles from the result
端点: POST /search-people-by-url
get_profile_dataEnrich profile data, including experience, skills, language and companies.
端点: GET /
参数:
username (string) 必需: Example value: adamselipsky
search_peopleSearch profiles by a keyword. You may see less than 10 results per page. This is because not return all profiles as public, sometimes hiding profiles and these profiles appear in the result. The endpoint automatically filters these profiles from the result
端点: GET /search-people
参数:
keywords (string): Example value: max
start (string): it could be one of these; 0, 10, 20, 30, etc.
geo (string): please follow this link to find location id
schoolId (string): Example value:
firstName (string): Example value:
lastName (string): Example value:
keywordSchool (string): Example value:
keywordTitle (string): Example value:
company (string): Company name
get_profile_data_by_urlGet all profile data, including experience, skills, language, education, course, and companies, open to work status, hiring status, location. Check Example Responses for more details
端点: GET /get-profile-data-by-url
参数:
url (string) 必需: Example value: https://www.linkedin.com/in/adamselipsky/
get_profile_group_interestsGet the profile's group interests up to 50 results per page
端点: POST /profiles/interests/groups
get_profile_top_voice_interestsGet the profile's top voices interests
端点: POST /profiles/interests/top-voices
get_profiles_postsGet last 50 posts of a profile. 1 credit per call
端点: GET /get-profile-posts
参数:
username (string) 必需: Example value: adamselipsky
start (string): use this param to get posts in next results page: 0 for page 1, 50 for page 2 100 for page 3, etc.
paginationToken (string): It is required when fetching the next results page. The token from the previous call must be used.
postedAt (string): It is not an official filter. It filters posts after fetching them from LinkedIn and returns posts that are newer than the given date. Example value: 2024-01-01 00:00
get_post_reactionsGet profiles that reacted to the post
端点: POST /get-post-reactions
get_profile_top_positionGet profile top position
端点: GET /profiles/positions/top
参数:
username (string) 必需: Example value: adamselipsky
get_companys_postGet last 50 posts of a company. 1 credit per call
端点: GET /get-company-posts
参数:
username (string) 必需: Example value: microsoft
start (string): use this param to get posts in next results page: 0 for page 1, 50 for page 2, 100 for page 3, etc.
paginationToken (string): It is required when fetching the next results page. The token from the previous call must be used.
get_company_pages_people_also_viewedGet Company Pages People Also Viewed
端点: GET /get-company-pages-people-also-viewed
参数:
username (string): Example value: google
get_company_insights_premiumGet Company Insight Details \u0026 Company Details in a single request. 5 credit per call. If the request fails, you don't pay.
端点: GET /get-company-insights
参数:
username (string) 必需: Example value: amazon
search_postsSearch Posts
端点: POST /search-posts
search_jobs_v2Search Jobs
端点: GET /search-jobs-v2
参数:
keywords (string) 必需: Example value: golang
locationId (number): please follow this link to find location id
companyIds (string): please follow this link to find company id
datePosted (string): it could be one of these; anyTime, pastMonth, pastWeek, past24Hours
salary (string): it could be one of these; 40k+, 60k+, 80k+, 100k+, 120k+, 140k+, 160k+, 180k+, 200k+ Example: 80k+
jobType (string): it could be one of these; fullTime, partTime, contract, internship Example: contract
experienceLevel (string): it could be one of these; internship, associate, director, entryLevel, midSeniorLevel. executive example: executive
titleIds (string): please follow this link to find title id by title
functionIds (string): please follow this link to find function id
start (string): it could be one of these; 0, 50, 100, 150, 200, etc. The maximum number of start is 975
industryIds (string): please follow this link to find industry id
onsiteRemote (string): it could be one of these; onSite remote hybrid example: remote
sort (string): it could be one of these; mostRelevant, mostRecent
distance (string): 0 = 0km 5 = 8km 10 = 16km 25 = 40km 50 = 80km 100 = 160km
get_profiles_posted_jobsGet profile's posted jobs.
端点: GET /profiles/posted-jobs
参数:
username (string) 必需: LinkedIn job id
get_company_post_commentsGet comments of a company post
端点: GET /get-company-post-comments
参数:
urn (string) 必需: Example value: 7179144327430844416
sort (string) 必需: Example value: mostRelevant
page (string): Example value: 1
get_company_employees_countGet company employees count (location filter possible)
端点: POST /get-company-employees-count
search_companiesSearch companies
端点: POST /companies/search
get_job_detailsGet the full job details, including the job skills and the company information
端点: GET /get-job-details
参数:
id (number) 必需: Example value: 4090994054
get_article_commentsGet article comments with url
端点: GET /get-article-comments
参数:
url (string) 必需: Example value: https://www.linkedin.com/pulse/2024-corporate-climate-pivot-bill-gates-u89mc/?trackingId=V85mkekwT9KruOXln2gzIg%3D%3D
page (string): Example value: 1
sort (string): Example value: REVERSE_CHRONOLOGICAL
get_article_reactionsGet article reactions with url
端点: GET /get-article-reactions
参数:
url (string) 必需: Example value: https://www.linkedin.com/pulse/2024-corporate-climate-pivot-bill-gates-u89mc/?trackingId=V85mkekwT9KruOXln2gzIg%3D%3D
page (string): Example value: 1
get_articleGet article with url
端点: GET /get-article
参数:
url (string) 必需: Example value: https://www.linkedin.com/pulse/hidden-costs-unreliable-electricity-bill-gates/
get_user_articlesGet user articles by profile with url or username
端点: GET /get-user-articles
参数:
url (string): Example value: https://www.linkedin.com/in/williamhgates/
username (string): Example value: williamhgates
get_post_repostsGet post reposts by post url
端点: POST /posts/reposts
get_postGet post details
端点: GET /get-post
参数:
url (string) 必需: Example value: https://www.linkedin.com/feed/update/urn:li:activity:7219434359085252608/
get_company_jobsGet company jobs
端点: POST /company-jobs
search_jobsSearch Jobs
端点: GET /search-jobs
参数:
keywords (string) 必需: Example value: golang
locationId (number): please follow this link to find location id
companyIds (string): please follow this link to find company id
datePosted (string): it could be one of these; anyTime, pastMonth, pastWeek, past24Hours
salary (string): it could be one of these; 40k+, 60k+, 80k+, 100k+, 120k+, 140k+, 160k+, 180k+, 200k+ Example: 80k+
jobType (string): it could be one of these; fullTime, partTime, contract, internship Example: contract
experienceLevel (string): it could be one of these; internship, associate, director, entryLevel, midSeniorLevel. executive example: executive
titleIds (string): please follow this link to find title id by title
functionIds (string): please follow this link to find function id
start (string): it could be one of these; 0, 25, 50, 75, 100, etc. The maximum number of start is 975
industryIds (string): please follow this link to find industry id
onsiteRemote (string): it could be one of these; onSite remote hybrid example: remote
sort (string): it could be one of these; mostRelevant, mostRecent
health_checkHealth Check
端点: GET /health
get_hiring_teamGet hiring team/job poster profile details. You can use either a job id or a job URL. One of these is required.
端点: GET /get-hiring-team
参数:
id (string): LinkedIn job id
url (string): LinkedIn job url
search_locationsSearch locations by keyword
端点: GET /search-locations
参数:
keyword (string) 必需: Example value: berlin
search_post_by_hashtagSearch Post by Hashtag
端点: POST /search-posts-by-hashtag
get_company_jobs_countGet total number of opening jobs the company
端点: GET /get-company-jobs-count
参数:
companyId (string) 必需: Example value: 1441
get_profile_recent_activity_timeGet the time of the profile's last activity
端点: GET /get-profile-recent-activity-time
参数:
username (string) 必需: Example value: adamselipsky
传输协议: stdio
HTTP 客户端: httpx
MIT License - 详见 LICENSE 文件。
此服务器由 API-to-MCP 工具生成。
版本: 1.0.0
Get profile verification details, profile’s joined, contact information updated, and profile photo updated date
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: williamhgates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavior. It implies read-only but does not confirm auth requirements, rate limits, or any side effects. Listing returned fields is basic but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently lists the returned fields. No waste, but could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description provides the essential information. However, it fails to distinguish from siblings, reducing contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described by example. The description adds no additional meaning to the parameter, meeting the baseline of 3 per rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'profile' and lists specific data fields. However, it does not differentiate from similar sibling tools like get_profile_data, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given many sibling tools with overlapping purposes, the lack of usage context 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.
Get article with url
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/pulse/hidden-costs-unreliable-electricity-bill-gates/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention whether the tool is read-only, requires authentication, has rate limits, or error handling. This is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only 4 words, which is extremely concise but under-specified. It lacks sufficient detail to be useful, bordering on tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and minimal description, the tool definition is incomplete. It does not explain what the tool returns, any prerequisites, or constraints, especially given the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description adds no additional meaning beyond 'with url', which is already implied by the parameter name and example.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get article with url' clearly indicates the action and resource, but it does not differentiate this tool from siblings like get_article_comments or get_post. The addition 'with url' is redundant given the input schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many sibling tools (e.g., get_article_comments, get_post), and the description gives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get article comments with url
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/pulse/2024-corporate-climate-pivot-bill-gates-u89mc/?trackingId=V85mkekwT9KruOXln2gzIg%3D%3D | |
| page | No | Example value: 1 | |
| sort | No | Example value: REVERSE_CHRONOLOGICAL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning pagination behavior, rate limits, or whether comments are returned in full. The schema hints at pagination via the 'page' parameter, but this is not clarified in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ultra-concise with a single sentence. No fluff, but it may be too brief to fully inform the agent. Still, it is efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description does not explain what the tool returns (e.g., list of comments with details) or how it differs from related tools. Important context for an agent deciding between tools is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with example values for all three parameters. The description adds no additional meaning beyond what the schema provides, 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.
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 'article comments', and includes 'with url' indicating the primary parameter. However, it does not differentiate from sibling tools like get_article_reactions, which also retrieve feedback on articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_article or get_article_reactions. There is no mention of prerequisites, fallbacks, or 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.
Get article reactions with url
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/pulse/2024-corporate-climate-pivot-bill-gates-u89mc/?trackingId=V85mkekwT9KruOXln2gzIg%3D%3D | |
| page | No | Example value: 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not mention whether the operation is read-only, requires authentication, or any side effects. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (5 words), but lacks structure or front-loading of critical info. While not verbose, it sacrifices completeness, making it minimally adequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description fails to explain return values, pagination behavior, or what 'reactions' means. For an agent to correctly invoke and use results, more context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no extra meaning beyond the schema's example values; 'with url' is redundant. Agent gains no parametric insight beyond what is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get article reactions with url', specifying the verb and resource. However, it does not differentiate from sibling 'get_post_reactions' or clarify what constitutes 'reactions' (e.g., likes, emojis), limiting its usefulness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_article_comments' or 'get_post_reactions'. No context about prerequisites, pagination, or limitations is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich the company data by domain. 1 credit per successful request.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes | Example value: apple.com |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only adds a credit cost disclosure. It does not confirm whether the operation is read-only, destructive, or requires authentication, leaving behavioral traits unclear beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a credit note. There is no waste, though it could benefit from slight restructuring to front-load the action more explicitly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description does not explain what company data is returned (e.g., fields, enrichment details). For a tool with one parameter, this is a notable gap in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the domain parameter. The description adds no additional meaning or format details beyond what the schema provides (example value). Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enrich the company data') and the method ('by domain'), distinguishing it from sibling tools like get_company_details or get_company_jobs that have different parameters or specific focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_company_details vs. by domain). The description lacks any context for selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The endpoint enrich full details of the company
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: google |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only says 'enrich full details' without disclosing behavioral traits like authentication needs, error handling, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but grammatically awkward ('The endpoint enrich'). It is concise but lacks proper structure and clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no output schema and no annotations, the description is insufficient. It does not explain the return format, error scenarios, or what 'full details' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds no new meaning beyond the schema's example value; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'enrich full details of the company', clearly indicating it returns comprehensive company data. However, it does not distinguish from sibling tools like get_company_by_domain or get_company_details_by_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Siblings with similar names exist, but the description offers no differentiation criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The endpoint enrich full details of the company
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 1441 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states it 'enrich full details', without mentioning permissions, side effects, rate limits, or any constraints. This is insufficient for a mutation tool (though it likely reads).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at one sentence but uses an awkward verb ('enrich') and lacks clarity. It could be rewritten more clearly without increasing length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and the presence of many sibling tools (e.g., 'get_company_details', 'get_company_insights_premium'), the description does not clarify what 'full details' includes or how this tool differs. The tool is under-described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully describes the 'id' parameter. The description adds no additional meaning beyond the example value already in the schema. Baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description indicates the tool retrieves full company details by ID. Although the verb 'enrich' is non-standard, the purpose is clear. It does not explicitly distinguish from sibling 'get_company_details', but the '_by_id' suffix in the name adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_company_details' or 'get_company_by_domain'. The description lacks any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company employees count (location filter possible)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose behavioral traits like authentication requirements, rate limits, or the nature of the count (e.g., real-time vs cached). The mention of a location filter without supporting parameters is also misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should provide context on what is returned (e.g., a number, an object). It does not explain the output format or result structure, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. However, the description adds 'location filter possible' which does not align with the schema, adding confusion rather than clarity. Thus a score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get company employees count' with a possible location filter, distinguishing it from sibling tools like 'get_company_jobs_count'. However, the location filter is not reflected in the input schema, which may cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as 'get_company_details' or 'get_company_jobs_count'. The description lacks any contextual hints for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get company jobs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no behavioral information in the description (e.g., destructive/read-only, authentication needs, rate limits); the agent has no insights into side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three-word description is extremely terse but merely repeats the tool name, adding no new information and failing to earn its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and many sibling tools, the description provides no contextual guidance on prerequisite state (e.g., company context) or expected output, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters with 100% coverage, so description adds no parameter-level detail; baseline 3 is appropriate as the schema already fully documents the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get company jobs' is vague; it doesn't specify what it returns (list/details) or how the company is identified, and fails to differentiate from sibling tools like search_jobs or get_company_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as search_jobs or get_job_details, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total number of opening jobs the company
| Name | Required | Description | Default |
|---|---|---|---|
| companyId | Yes | Example value: 1441 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It states 'Get total number' but does not mention whether the count is live, cached, or subject to rate limits. It also doesn't confirm that this is a read-only operation (though implied). No side effects or authorization requirements are described, leaving the agent partially in the dark.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is concise and front-loaded with the action. However, it could be restructured for clarity (e.g., 'Get the total number of opening jobs for a company'). Still, it meets efficiency standards.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description should clarify the return format (e.g., integer count) and the meaning of 'opening jobs' (e.g., actively recruiting positions). It lacks these details, and with no output schema, the agent has no way to know what the response structure is. The description also fails to differentiate from similar count tools among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the only parameter 'companyId', providing an example value. The description adds no additional meaning beyond that. Per guidelines, when schema coverage is high, a score of 3 is appropriate as baseline, and the description does not elevate it by adding context like parameter format or source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and specifies the resource 'total number of opening jobs', making the core purpose clear. It also naturally distinguishes from sibling tools like 'get_company_jobs' (which likely lists jobs) and 'get_company_employees_count'. However, the phrasing is slightly awkward, missing 'for' before 'the company'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it doesn't explain that this tool returns a count while 'get_company_jobs' returns a list, nor does it suggest when one is preferred over the other. There is no context on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Company Pages People Also Viewed
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Example value: google |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits (e.g., authentication needed, rate limits, or whether the tool returns a list or details).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence echoing the tool name. While short, it lacks useful structure or front-loading of key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description fails to explain what the tool returns or how to interpret results, leaving the agent underinformed for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'username' with example 'google'. The description adds no additional meaning beyond the schema, so baseline score applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Company Pages People Also Viewed' indicates the tool retrieves company pages related to user viewing patterns, but the parameter 'username' is ambiguous (typically for persons, not companies), causing confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_company_details or get_companys_post. The description lacks context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments of a company post
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | Example value: 7179144327430844416 | |
| sort | Yes | Example value: mostRelevant | |
| page | No | Example value: 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description offers no behavioral information beyond the action. It does not mention rate limits, authentication needs, sorting behavior, pagination details, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (4 words) and front-loaded. However, it is too terse and sacrifices necessary details for completeness. It could be improved by adding brief context on usage or parameters.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and an average complexity of 3 parameters, the description is incomplete. It fails to explain return format, pagination, sorting behavior, or any constraints, leaving the agent underinformed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all three parameters described, albeit with only example values. The description adds no additional meaning beyond the schema. Baseline is 3 due to high coverage, but weak parameter descriptions prevent a higher score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'comments of a company post'. It is specific enough to avoid confusion with generic comment retrievers, but it does not differentiate from siblings like 'get_profiles_comments' or 'get_post'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. For example, one might use 'get_post' to retrieve comments along with the post, or 'get_profiles_comments' for a different user context. The description lacks any context about prerequisites or 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.
Get last 50 posts of a company. 1 credit per call
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: microsoft | |
| start | No | use this param to get posts in next results page: 0 for page 1, 50 for page 2, 100 for page 3, etc. | |
| paginationToken | No | It is required when fetching the next results page. The token from the previous call must be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions credit cost but does not disclose pagination behavior beyond parameter hints, nor does it describe what happens on errors or rate limits. Minimal behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. Information is front-loaded and concise. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, yet description does not specify return structure or format. It mentions 'last 50 posts' but not field details. For a simple list retrieval, it is barely adequate but missing important context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and schema descriptions are already clear. The description adds no additional meaning beyond '1 credit per call'. It could have elaborated on username format or pagination behavior but did not.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (last 50 posts of a company). It distinguishes from siblings like 'get_post' and 'get_company_post_comments' by specifying company scope and count. However, the name 'get_companys_post' is slightly ambiguous and could be clearer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over alternatives. Sibling tools like 'get_post', 'get_profiles_posts', and 'get_company_post_comments' exist but no conditions or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
To scrape all recommendations from a profile, increase the start value to +100 for each request until you reach the total recommendations count. You can find the total recommendations count in the response
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: ryanroslansky | |
| start | No | Example value: 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the pagination requirement and that total count is in the response, but omits potential issues like invalid start values, rate limits, or empty responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, direct and informative. No wasted words, but could be slightly reorganized to front-load the purpose. Still, efficient for the content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema and no description of the response structure beyond total count. For a scraping tool, an agent needs to know how to extract data from the response. Also, no comparison to similar siblings like 'get_received_recommendations'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but only provides example values. The description adds meaning by explaining that 'start' is used for pagination with increments of 100, which is essential for usage. 'username' is self-explanatory.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('scrape all recommendations') and resource ('from a profile'). The tool name includes 'given', distinguishing it from the sibling 'get_received_recommendations', so the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit pagination instructions: increment start by 100 until total count, which is found in the response. This tells the agent exactly how to iterate through all recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get hiring team/job poster profile details. You can use either a job id or a job URL. One of these is required.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | LinkedIn job id | |
| url | No | LinkedIn job url |
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 does not mention authentication needs, rate limits, side effects (though likely read-only), or behavior when no team is found. This lack of detail limits transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, with no wasted words. The key action and parameter constraint are front-loaded, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description covers the essential inputs and purpose. However, it lacks guidance on return format or edge cases. Given the low complexity, it is nearly complete but could benefit from mentioning expected output (e.g., names, roles).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameters as 'LinkedIn job id' and 'LinkedIn job url'. The description adds the crucial semantic constraint that exactly one of these is required, which is not enforced in the schema's 'required' array. This adds meaningful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves hiring team or job poster profile details, using a specific verb ('Get') and resource. This distinguishes it from sibling tools like 'get_job_details' (which focuses on job posting details) and various profile getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies that either a job ID or URL must be provided, clarifying the parameter requirement. However, it does not explicitly state when to use this tool over alternatives like 'get_profile_data' or 'get_job_details', nor does it provide when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full job details, including the job skills and the company information
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Example value: 4090994054 | 4090994054 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only describes a read operation but omits important details like authentication requirements, rate limits, or potential large payloads. The description is minimal and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence without wasted words. It could be slightly improved by structuring the output components separately, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple input (one required parameter) and no output schema, the description adequately states what the tool returns (job details, skills, company info). However, it lacks specificity about the output structure or potential constraints, leaving some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter ('id') described only by an example value. The tool's description mentions the output (skills, company info) but adds no extra meaning to the parameter beyond what the schema provides. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'full job details', and specifies that it includes job skills and company information. This distinguishes it from sibling tools like 'get_company_jobs' or 'search_jobs', though it could be more explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'search_jobs', 'get_company_jobs', or 'get_company_details'. It assumes the agent already has a job ID and gives no context about prerequisites or excluded use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get post details
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/feed/update/urn:li:activity:7219434359085252608/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks side effects, permissions, or result scope; only states action without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Excessively short; two words do not earn their place as they add minimal value beyond the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema; description omits what 'details' include; incomplete for a simple GET command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Single parameter with schema coverage 100%; description adds no extra meaning beyond schema example, baseline 3 per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description 'Get post details' is a verb+resource but generic; does not distinguish from sibling tools like get_article or get_post_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profiles that reacted to the post
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 fails to specify whether the tool is read-only, requires authentication, has rate limits, or what the output format is. The minimal description offers no transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no unnecessary words. However, it is too brief and omits critical details, which slightly detracts from its effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no output schema, and no annotations, the description must be self-contained. It does not explain how the post is specified, what the return value looks like, or any potential constraints. This incompleteness forces the agent to rely on assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. However, the description does not clarify how the post is identified (e.g., implicitly from context), which is a gap. Since there are no parameters to describe, the score is reduced for missing contextual details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'profiles that reacted to the post', which is clear in general but lacks specificity on how the post is identified. Since the input schema has no parameters, the description does not explain how the target post is determined, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_article_reactions or get_profile_reactions. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get post reposts by post url
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely states 'Get', implying a read operation but offering no details on behavior, response format, limitations, or pagination. The description adds minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one sentence, but it omits critical information about how the post URL is provided. Conciseness is not beneficial when it leads to incompleteness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description is severely incomplete. It does not explain how the URL is passed, what data is returned, or any prerequisites, leaving the agent without enough context to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description mentions 'by post url', implying a parameter that does not exist. This contradiction undermines parameter semantics; the description adds confusion rather than value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get post reposts by post url', clearly identifying the resource (post reposts) and a criterion (by post url). However, the input schema has no parameters defined, making it unclear how the URL is provided. This confusion detracts from clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives such as get_post_reactions or get_post. The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile's company interests up to 50 results per page.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions a pagination limit (50 results per page) but does not disclose authentication needs, rate limits, or behavior when no interests exist. With no annotations, this is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the verb 'Get', and no unnecessary words. Efficient communication.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about the return structure, pagination mechanism, and how the profile is identified. No output schema or annotations exist, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the schema, so the description adds value by specifying the 50 results per page constraint. The schema coverage is 100%, and the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the profile's company interests with a limit of 50 per page. It is specific but does not differentiate from sibling tools like get_profile_group_interests, though the name suggests the domain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are many sibling tools for different interest types, but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Profile Connection \u0026 Follower Count
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits such as read-only nature, rate limits, or required permissions. The agent gets no safety cues.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short, which could be efficient, but it lacks necessary detail. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is completely inadequate given the lack of output schema and annotations. It does not help the agent understand the tool's behavior or output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds no meaning beyond the schema. The parameter 'username' is not explained, and the description does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology of the tool name ('Get Profile Connection & Follower Count'), providing no additional information about what is retrieved (e.g., counts or lists) or how it differs from siblings like 'get_profile_data_and_connection_u0026_follower_count'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. With multiple similar profile tools, the agent cannot determine the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Enrich profile data, including experience, skills, language and companies.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as whether the tool is read-only, authorization needs, or error handling. It only lists data categories without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence with no superfluous words. It could be slightly more structured (e.g., bullet points), but it efficiently conveys the core idea.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and the presence of many similar sibling tools, the description is insufficient. It does not explain the return structure, edge cases, or how this tool differs from others like 'get_profile_data_by_url'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'username' is described in the schema with an example value. The tool description adds value by indicating what data is returned (experience, skills, etc.), but does not clarify the format or constraints of the username parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'enrich[es] profile data' and lists categories (experience, skills, language, companies), which gives a sense of purpose. However, 'enrich' is vague and doesn't clearly differentiate from sibling tools like 'get_profile_data_and_connection_follower_count_and_pos'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus the many sibling tools. There is no mention of when-not-to-use or alternative tools, leaving the agent to guess the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Profile Data and Connection \u0026 Follower Count
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It fails to mention any side effects, authentication needs, rate limits, or data scope (e.g., whether it returns raw counts or processed data). The description is purely nominal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but at the cost of being a tautology—it merely repeats the tool name. It does not earn its place by providing useful information; it is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high number of similar siblings and the lack of output schema, the description is woefully incomplete. It does not explain what data is returned, how it differs from 'get_profile_data' or 'get_profile_connection_u0026_follower_count', or any usage caveats.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters and provides an example value for 'username'. The description does not add any additional meaning beyond what the schema already states, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Profile Data and Connection & Follower Count' restates the tool name almost verbatim and does not differentiate it from closely related siblings like 'get_profile_data' or 'get_profile_connection_u0026_follower_count'. It lacks specificity on what exactly is returned versus those tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives. With siblings that have overlapping names (e.g., 'get_profile_data_connection_u0026_follower_count_and_pos'), the agent has no way to decide which to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all profile data, including experience, skills, language, education, course, and companies, open to work status, hiring status, location. Check Example Responses for more details
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/in/adamselipsky/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only lists returned fields and references example responses, but omits authentication needs, rate limits, or any side effects (e.g., read-only nature).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an additional note to check examples, making it concise. However, it lacks structure and could be improved by including a bullet list or explicit fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lists included fields but does not fully compensate for missing output schema. It references 'Example Responses' but does not detail return format. Given the tool's simplicity (1 param) and many siblings, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'url' parameter with an example. The description adds no further semantics beyond the schema, which already covers it fully (100% coverage). Scoring baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves profile data, listing specific fields (experience, skills, etc.). However, it does not distinguish itself from the sibling 'get_profile_data', which likely serves a similar purpose with a different input.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_profile_data' or 'get_profile_data_and_connection_u0026_follower_count'. The agent has no help choosing among many similar profile tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Profile Data, Connection \u0026 Follower Count and Posts. 2 credits per call
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions credit cost, but no disclosure of other behaviors (e.g., idempotency, side effects, return structure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short and efficient, but lacks structure like section headers. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Description does not specify what data is returned (e.g., fields, pagination) despite no output schema. Incomplete for a tool with many siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an example value. Tool description adds no additional meaning beyond the schema, so baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states it gets profile data, connection/follower count, and posts. However, it does not differentiate from sibling tools like get_profile_data or get_profile_connection_u0026_follower_count, making selection ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile's group interests up to 50 results per page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must cover behavioral traits. Only mentions a result limit but doesn't indicate pagination mechanism, authorization needs, or whether it's read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with action. Very concise, but could benefit from adding more context without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details like which profile (e.g., authenticated user), return format, and how pagination works. For a tool with no parameters and no output schema, description is insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (100% coverage trivially), so baseline 3 applies. Description doesn't add parameter info but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves 'profile's group interests' with a specific limit of 50 per page, distinguishing it from sibling tools like get_profile_school_interests and get_profile_newsletter_interests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, or when not to use it. The description only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile's newsletter interests up to 50 results per page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only notes a pagination limit but omits whether the tool requires authentication, is read-only (likely), or has rate limits. No side effects or authorization requirements are mentioned, leaving 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It efficiently communicates the tool's purpose and a key constraint. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the core action and a pagination detail. However, it fails to specify which profile (e.g., the authenticated user's) or any return format. While adequate for a simple tool, it leaves the agent guessing about scope and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and is fully covered (100%), so the description adds no parameter-specific information. The baseline of 3 applies as the schema itself is sufficient. The mention of 'up to 50 per page' is a behavioral note, not parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('profile's newsletter interests'), clearly indicating what the tool retrieves. It distinguishes itself from siblings like get_profile_group_interests or get_profile_school_interests by focusing on newsletter interests. The mention of pagination (up to 50 per page) adds precision.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any prerequisites, exclusions, or compare to other interest tools. The agent receives no context about which profile is queried or when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Profile Positions With Skills
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: tedgaubert |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description offers no behavioral traits such as read-only status, authentication needs, or data scope. The agent has no insight into side effects or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but that sentence is a direct restatement of the tool name, making it under-specified. It lacks structure and fails to convey useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and a single parameter, the description is wholly inadequate for an agent to understand the tool's functionality or context. It does not explain what 'positions with skills' means or how it differs from similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (one parameter with example), the description adds zero semantic value. It merely restates the tool name, providing no additional meaning about the parameter's purpose or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get Profile Positions With Skills' is a tautology of the tool name. It does not specify a clear verb or resource beyond what the name already conveys, and fails to differentiate from sibling tools like 'get_profile_top_position' or 'get_profile_data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. With numerous sibling tools for profiles and positions, the agent receives no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profile post and comments of the post
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | URN value of the post. Example URL: https://www.linkedin.com/posts/andy-jassy-8b1615_amazon-bedrock-customers-have-more-choice-activity-7181285160586211328-Idxl/?utm_source=share&utm_medium=member_desktop Example URN: 7181285160586211328 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must fully disclose behavioral traits. It does not mention read-only nature, authentication requirements, rate limits, or any side effects. The description is insufficient for an agent to assess safety or constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure. It could be expanded slightly to improve clarity without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and minimal description, the tool is missing important context about return format (e.g., does it return both post and comments in one response?), pagination, or error handling. It is not complete enough for an agent to reliably invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema already describes the 'urn' parameter with an example. The tool description adds no additional semantic information beyond what the schema provides, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get profile post and comments of the post' clearly states the verb and resource (get post and comments). However, it does not differentiate from sibling tools like 'get_post' or 'get_profile_post_comment', and the term 'profile post' is ambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'get_post' for just the post, 'get_profile_post_comment' for just comments). The description lacks any contextual usage hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 50 comments of a profile post (activity)
| Name | Required | Description | Default |
|---|---|---|---|
| urn | Yes | Post urn value | |
| sort | Yes | it could be one of these; mostRelevant, mostRecent | |
| page | No | Example value: 1 | |
| paginationToken | No | It is required when fetching the next results page. The token from the previous call must be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must convey behavior. It states the operation is reading ('Get'), but omits details such as authentication requirements, behavior for posts with fewer than 50 comments, or pagination implications. The parenthetical '(activity)' adds minimal context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) and front-loaded, but overly minimal given the tool's complexity. It sacrifices completeness for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It mentions '50 comments' yet the schema indicates pagination (paginationToken), suggesting more than 50 may be accessible. The description lacks operational details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters documented. The description adds no additional meaning beyond the schema, earning a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 50 comments from a profile post with a specific verb and resource. It distinguishes from siblings like get_article_comments by specifying 'profile post' and a fixed count, but does not fully differentiate from get_profiles_comments.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus siblings like get_article_comments or get_profile_post_and_comments. There is no mention of prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find out what posts a profile reacted to
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky | |
| start | No | for pagination, increase +100 to parse next result until you see less than 100 results. it could be one of these; 0, 100, 200, 300, 400, etc. | |
| paginationToken | No | It is required when fetching the next results page. The token from the previous call must be used. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It only says what the tool does, not how it behaves—no mention of pagination behavior, ordering, rate limits, or reaction details. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words, front-loaded. However, it border on under-specification, but conciseness for its length is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the need for pagination and no output schema, the description fails to provide enough context. It doesn't describe the return format, errors, or intended use patterns, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no value beyond the schema; it doesn't explain the relationship between 'start' and 'paginationToken' or how to paginate correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves posts a profile reacted to, using a specific verb-resource combination. It distinguishes from siblings like get_post_reactions, but the verb 'find out' is slightly vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_post_reactions. Missing context on how pagination parameters interplay. No explicit when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the time of the profile's last activity
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description only states the basic function; does not disclose output format, authentication needs, or any constraints beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words; front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite simplicity, description fails to mention return type or format; with no output schema, more detail is needed for an agent to correctly interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage with an example value, meeting baseline; description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the time of a profile's last activity, with verb 'Get' and specific resource. It is distinct from sibling tools like get_profile_data or get_profile_reactions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; lacks context for selection among many profile-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile's school interests up to 50 results per page
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It mentions pagination (up to 50 results per page) but does not state whether the operation is read-only, what authentication is needed, or if there are rate limits. The safety profile is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded with the verb and resource. No extraneous words. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description explains the core function and pagination but omits output format and scope relative to siblings. Adequate for low complexity but leaves some questions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds value by explaining the resource and pagination. Baseline is 4 for zero-parameter tools. It would benefit from describing what 'school interests' means but is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'profile's school interests' with a pagination constraint. However, it does not differentiate itself from sibling tools like get_profile_group_interests, as the only distinction is the resource name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidelines are provided on when to use this tool versus siblings or what context is assumed (e.g., which profile). The description lacks any conditional or alternative usage considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get last 50 comments of a profile. 1 credit per call
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: williamhgates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; description only mentions '1 credit per call' but does not disclose other behavioral traits like rate limits, authentication needs, or side effects. Limited transparency for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-load the action and cost. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple tool: states purpose and cost. Lacks details about output format or any additional constraints beyond 'last 50', but sufficient for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described with example). Description adds no additional meaning beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb ('Get'), resource ('last 50 comments of a profile'), and distinguishes it from sibling tools like get_article_comments or get_profile_post_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. No when/why not or usage context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profile's posted jobs.
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | LinkedIn job id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It does not mention read-only nature, authentication requirements, response format, or pagination, leaving the agent uninformed about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence that directly states the action. It is concise without being overly terse, though it could benefit from a bit more detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with simple inputs but no output schema or annotations, the description fails to explain what data is returned (e.g., list of job details) or how to interpret results. The parameter confusion compounds the issue.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the parameter description 'LinkedIn job id' conflicts with the parameter name 'username', creating confusion. The tool description adds no additional clarity or usage tips.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves posted jobs for a profile. The verb 'Get' and resource 'profile's posted jobs' are specific, but it lacks differentiation from similar sibling tools like get_profiles_posts or get_company_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_profiles_posts or search_jobs. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get last 50 posts of a profile. 1 credit per call
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky | |
| start | No | use this param to get posts in next results page: 0 for page 1, 50 for page 2 100 for page 3, etc. | |
| paginationToken | No | It is required when fetching the next results page. The token from the previous call must be used. | |
| postedAt | No | It is not an official filter. It filters posts after fetching them from LinkedIn and returns posts that are newer than the given date. Example value: 2024-01-01 00:00 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses credit cost (1 credit per call), which is helpful. However, no annotations exist, and description lacks detail on rate limits, side effects, or pagination nuances. Minor inconsistency: 'last 50' implies a fixed set, but schema supports pagination for more results.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (two sentences), but lacks structure. The single functional sentence could be more informative, and the credit mention is useful but not fully earned.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters, no output schema, and no annotations, the description is insufficient. It does not explain response format, pagination behavior (start, paginationToken), or how 'postedAt' filter works, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema covers 100% of parameters with descriptions. The description adds no additional meaning beyond 'Get last 50 posts', so baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states 'Get last 50 posts of a profile', providing a specific verb and resource. It clearly distinguishes from sibling tools like 'get_post' (single post) and 'get_article' (articles).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., 'get_profile_data', 'get_profiles_comments'). Missing context on preferred use cases or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get profile top position
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: adamselipsky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits, but it only says 'Get profile top position'. It does not state whether the operation is read-only, what permissions are needed, or what the response structure is. Critical information is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it fails to be informative. It does not earn its place as every sentence should.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description is incomplete. It does not explain what 'top position' means (e.g., most recent, highest ranking), which is crucial for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter with description and example), so baseline is 3. The description adds no additional meaning beyond what the schema provides, earning the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get profile top position', which is a clear verb+resource combination. However, it does not differentiate from sibling tools like get_profile_positions_with_skills or get_profile_data, leaving ambiguity about what 'top position' specifically refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_profile_positions_with_skills or get_profile_data. The description lacks any context about prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the profile's top voices interests
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only nature, authentication requirements, return format). The tool has no parameters, but the description fails to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence), but it is lacking in structure and detail. While it avoids verbosity, it could include more context without being lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (no parameters, no output schema) and the presence of many sibling tools, the description is incomplete. It does not explain what 'top voices interests' means, leaving the agent to guess its specific purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (no parameters), so baseline is 3. Description adds no additional meaning beyond the schema, but it's acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'profile's top voices interests'. It is not a tautology, but it does not distinguish from sibling tools like get_profile_group_interests or get_profile_newsletter_interests.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The agent has no context for selecting this tool among many similar profile interest tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
To scrape all recommendations from a profile, increase the start value to +100 for each request until you reach the total recommendations count. You can find the total recommendations count in the response
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: ryanroslansky | |
| start | No | Example value: 0 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries full burden. It reveals pagination behavior and mentions 'total recommendations count' in response, but omits details like authorization needs, rate limits, or statefulness of repeated calls. Lacks full transparency for a scraping tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence covers the core instruction but is somewhat run-on. Information is front-loaded with purpose, but could be split for clarity. Acceptable but not highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains pagination to retrieve all recommendations, given no output schema. However, lacks description of response structure for individual recommendations, which is needed for complete understanding. Sufficient for basic use with trial-and-error.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with examples. Description adds meaning by explaining 'start' is for pagination and increments by 100, which is not evident from schema alone. The total count reference also adds context for the response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool scrapes 'all recommendations from a profile', indicating it retrieves received recommendations. It distinguishes implicitly from sibling 'get_given_recommendations' by not mentioning 'given', but does not explicitly state 'received'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit pagination instructions (increase start by 100 until total count), but no direct comparison with alternatives like 'get_given_recommendations' or 'profile_data_&_recommendations'. The context is clear for pagination usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns profiles that are similar to the provided profile
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Example value: https://www.linkedin.com/in/williamhgates/ |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose any behavioral traits (e.g., read-only, authentication needs, rate limits). For a tool without annotations, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with essential information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description does not explain the output format, pagination, or any edge cases. For a tool returning a list of profiles, more detail is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter, and the parameter's schema already includes an example. The description adds no further semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool returns profiles similar to a given profile. It distinguishes from siblings like get_profile_data, which returns data for a specific profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., search_people). The description provides no context for optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get user articles by profile with url or username
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Example value: https://www.linkedin.com/in/williamhgates/ | |
| username | No | Example value: williamhgates |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry burden. It gives zero behavioral details (e.g., pagination, return format, authentication). Merely states purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with no filler. It front-loads the action and resource effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, no annotations. The description does not explain return values, edge cases (both params provided or none), or any other context needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already provides example descriptions for both parameters. The description essentially repeats that the tool works 'by profile with url or username', adding no semantic value beyond what schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'user articles', and the identification method 'by profile with url or username'. It distinguishes from siblings like get_article (singular) and profile data tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_article. No instruction on which parameter to prefer (url vs username) when both are optional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Health Check
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. 'Health Check' gives no information about whether the tool is read-only, destructive, requires authentication, or has side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
At two words, the description is extremely concise but underspecified to the point of being unhelpful. It fails to provide necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no description of return values, the tool is completely opaque. The description does not suffice for an agent to understand what the tool does or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline is 3. The description adds no parameter information, but there are none to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Health Check' is a tautology that restates the tool name without adding a specific verb or clarifying the resource being checked. It fails to indicate what the tool does or distinguish it from the many sibling data retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description lacks context about its purpose relative to the other tools on the server.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get Profile Data, Given and Received Recommendations. 2 credits per call
| Name | Required | Description | Default |
|---|---|---|---|
| username | Yes | Example value: ryanroslansky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It only adds the credit cost (2 credits per call). No mention of error handling, data freshness, or other behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with purpose. The credit note is useful but adds minimal overhead. Could be slightly more structured but acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and the description does not detail what the returned data contains beyond a high-level list. Given the complexity of profile and recommendations data, this is insufficient for an agent to know how to use the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (username parameter with example). The description adds no extra meaning 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets profile data and both given/received recommendations. However, it doesn't differentiate from sibling tools like get_profile_data, get_given_recommendations, or get_received_recommendations, which each focus on a subset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this combined tool versus individual siblings. The credit cost is mentioned but not how it compares to using separate tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search companies
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as authentication requirements, read-only nature, pagination, rate limits, or any side effects. Fails to inform the agent about operational behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (two words) but at the cost of clarity. No structure, front-loading, or useful information. It is under-specified rather than efficiently minimal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters, no output schema, and no annotations, the description is entirely insufficient. The tool operates in a complex domain with many similar tools, yet the description provides no context about what it does or how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is higher. However, description adds no meaning beyond the name. It does not explain what 'search companies' means in terms of scope (e.g., all companies, by keyword, etc.). The information is barely above a restatement.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description is 'Search companies', which is a tautology of the tool name. It does not specify what kind of search, what filters or inputs are used, or what the tool returns. No distinction from sibling tools like search_people or search_jobs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. There are many sibling search tools, but the description provides no context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jobs
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Example value: golang | |
| locationId | No | please follow this link to find location id | 92000000 |
| companyIds | No | please follow this link to find company id | |
| datePosted | No | it could be one of these; anyTime, pastMonth, pastWeek, past24Hours | |
| salary | No | it could be one of these; 40k+, 60k+, 80k+, 100k+, 120k+, 140k+, 160k+, 180k+, 200k+ Example: 80k+ | |
| jobType | No | it could be one of these; fullTime, partTime, contract, internship Example: contract | |
| experienceLevel | No | it could be one of these; internship, associate, director, entryLevel, midSeniorLevel. executive example: executive | |
| titleIds | No | please follow this link to find title id by title | |
| functionIds | No | please follow this link to find function id | |
| start | No | it could be one of these; 0, 25, 50, 75, 100, etc. The maximum number of start is 975 | |
| industryIds | No | please follow this link to find industry id | |
| onsiteRemote | No | it could be one of these; onSite remote hybrid example: remote | |
| sort | No | it could be one of these; mostRelevant, mostRecent |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as read-only nature, rate limits, or side effects. The tool likely performs a search (assumed read-only), but this is not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief (two words), but it lacks substance. Conciseness should not sacrifice information; this under-specification does not help the agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, many siblings, no output schema), the description is woefully incomplete. It does not explain return format, filtering behavior, or how this search differs from other search tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema already documents all parameters thoroughly. The tool description adds no additional semantic value beyond what the schema provides, resulting in baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Jobs' is a tautology that merely restates the tool name without specifying what kind of job search, scope, or differentiation from siblings like search_jobs_v2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus similar alternatives (e.g., search_jobs_v2, get_company_jobs). The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Jobs
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | Yes | Example value: golang | |
| locationId | No | please follow this link to find location id | 92000000 |
| companyIds | No | please follow this link to find company id | |
| datePosted | No | it could be one of these; anyTime, pastMonth, pastWeek, past24Hours | |
| salary | No | it could be one of these; 40k+, 60k+, 80k+, 100k+, 120k+, 140k+, 160k+, 180k+, 200k+ Example: 80k+ | |
| jobType | No | it could be one of these; fullTime, partTime, contract, internship Example: contract | |
| experienceLevel | No | it could be one of these; internship, associate, director, entryLevel, midSeniorLevel. executive example: executive | |
| titleIds | No | please follow this link to find title id by title | |
| functionIds | No | please follow this link to find function id | |
| start | No | it could be one of these; 0, 50, 100, 150, 200, etc. The maximum number of start is 975 | |
| industryIds | No | please follow this link to find industry id | |
| onsiteRemote | No | it could be one of these; onSite remote hybrid example: remote | |
| sort | No | it could be one of these; mostRelevant, mostRecent | |
| distance | No | 0 = 0km 5 = 8km 10 = 16km 25 = 40km 50 = 80km 100 = 160km |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., rate limits, pagination, data freshness). The burden is entirely on the description, which is empty of such details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise but under-specified. It sacrifices informativeness for brevity, making it inadequate.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (14 parameters, no output schema) and the number of sibling search tools, the description is completely insufficient. It does not explain output, pagination, or filtering behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The tool description does not add any additional meaning beyond what the parameter descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search Jobs' is a tautology of the tool name and does not specify the verb, resource, or scope. It fails to distinguish this tool from siblings like 'search_jobs'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as 'search_jobs' or 'get_company_jobs'. The description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search locations by keyword
| Name | Required | Description | Default |
|---|---|---|---|
| keyword | Yes | Example value: berlin |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must standalone. It only states 'search' without disclosing whether results are paginated, what fields are returned, or any rate limits. The behavior is minimally implied as read-only, but specifics 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the core function without any unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is adequate but could be improved by briefly noting typical result count or the scope of locations searched.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'keyword', and the schema description already provides an example value. The tool description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb-resource structure ('Search locations by keyword'), but does not differentiate from sibling search tools like search_companies or search_people, which also search by keyword.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other search tools (e.g., search_people, search_jobs). No context on prerequisites 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.
Search profiles by a keyword. You may see less than 10 results per page. This is because not return all profiles as public, sometimes hiding profiles and these profiles appear in the result. The endpoint automatically filters these profiles from the result
| Name | Required | Description | Default |
|---|---|---|---|
| keywords | No | Example value: max | |
| start | No | it could be one of these; 0, 10, 20, 30, etc. | |
| geo | No | please follow this link to find location id | |
| schoolId | No | Example value: | |
| firstName | No | Example value: | |
| lastName | No | Example value: | |
| keywordSchool | No | Example value: | |
| keywordTitle | No | Example value: | |
| company | No | Company name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions that results may have fewer than 10 per page due to hidden profiles being filtered, which adds some behavioral context. However, the explanation is confusing and incomplete, lacking details on filtering logic or other behavioral traits like authentication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short at three sentences. The first sentence is clear, but the latter two are grammatically poor and confusing. It is not optimally front-loaded and could be more concise without the unclear elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and no annotations, the description is incomplete. It hints at pagination but does not explain search logic, result format, or how multiple parameters interact. Essential context for effective usage is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 9 parameters have descriptions). Baseline is 3. The tool description does not add parameter-specific meaning beyond the schema; it only mentions a keyword, ignoring other parameters like firstName, lastName, company. Thus, no extra value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search profiles by a keyword', indicating the verb and resource. It distinguishes from sibling tools like 'search_people_by_url' which searches by URL, but does not elaborate on the scope of keyword search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'search_people_by_url' or other search tools. The description implies it is for keyword-based profile search but provides no exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search profiles by a keyword. You may see less than 10 results per page. This is because not return all profiles as public, sometimes hiding profiles and these profiles appear in the result. The endpoint automatically filters these profiles from the result
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Claims 'less than 10 results per page' and 'hides profiles', but explanation is confusing and lacks details on why or authorization needs. No annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description has grammatical errors ('This is because not return') and is not concise. Every sentence is confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and few parameters; description fails to explain behavior clearly. Agent cannot determine how to invoke or what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, but description implies a 'keyword' parameter exists. Schema coverage is 100% (empty), yet description adds misleading info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'search' and resource 'profiles' are clear, but stating 'by a keyword' contradicts the empty input schema. No differentiation from sibling 'search_people'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like 'search_people'. Lacks exclusions or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Post by Hashtag
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read vs write, authentication needs, or rate limits. The description carries the full burden but offers nothing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (4 words) but fails to be useful; it is under-specified rather than concise. Every word should earn its place, but this just repeats the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is completely inadequate. It does not explain how the hashtag is supposed to be provided or what results are returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% trivial. Per rule, 0 params has baseline 4. The description adds no param info but also no omission.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is just a restatement of the name 'Search Post by Hashtag', providing no further detail about what the tool does, its scope, or output. It lacks a specific verb and resource beyond the name itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus siblings like 'search_posts', 'search_companies', etc. There is no mention of context, prerequisites, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Posts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits such as authentication requirements, scope of search, or side effects. It does none of this, leaving the agent blind to 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short (two words) but this is under-specification, not conciseness. It lacks structure and fails to provide essential information, making it unhelpful despite its brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (searches), lack of parameters, and absence of output schema and annotations, the description is severely incomplete. It provides none of the necessary context for safe and correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4 per the rule, but the description adds no meaning beyond the name. It fails to clarify what the tool returns or any implicit context, making it minimally helpful. A score of 2 reflects that the description adds almost no semantic value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a tautology, simply restating the tool name 'Search Posts' without specifying what is being searched (e.g., all posts, user posts, filtered by criteria). It provides no additional meaning or differentiation from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_post', 'get_profiles_posts', or 'search_post_by_hashtag'. The agent has no context to decide which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Multiple tools serve very similar purposes, such as several profile data retrieval tools (get_profile_data, get_profile_data_by_url, get_profile_data_and_connection_&_follower_count, etc.) and two search_jobs tools, making it difficult to distinguish the appropriate tool.
Naming conventions are inconsistent: most tools use 'get_' but some use 'search_', 'about_', or 'health_'. Additionally, some names include encoded characters like 'u0026' or ampersands, breaking uniformity.
With 52 tools, the count is high but not unreasonable for a comprehensive LinkedIn data API. However, substantial redundancy (e.g., multiple profile data variations) inflates the number unnecessarily.
The tool set covers a wide range of LinkedIn data: profiles, companies, jobs, posts, articles, search, and recommendations. Minor gaps exist, such as lack of write operations, but for a read-only data enrichment API, completeness is strong.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
LinkedIn: The LinkedIn Data API offers access to detailed information on individuals, companies.
Live LinkedIn data for AI agents: profiles, companies, jobs, posts, email finding. No account risk.
Full LinkedIn access for AI agents: leads, messaging, and campaigns with safe limits built in.
Search LinkedIn & Sales Navigator. Get structured people, companies, posts, jobs data. 4.9/5 on G2.
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-linkedin-data-api'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
