Click on "Deploy 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, the description must disclose behavioral traits. It only lists the data retrieved, but does not mention that it is read-only, requires no special permissions, or any potential side effects. The lack of behavioral context 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 a single, well-structured sentence that immediately states the verb and the data items. It is free of redundant information and every word adds value.
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?
While the description lists the fields returned, there is no output schema to specify the response structure. Combined with the lack of annotations and usage guidance, the description feels partially complete for a tool with only one input parameter.
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 describes the username parameter with an example, achieving 100% coverage. The description adds no additional meaning for the parameter beyond what the schema already 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 specifies the resource: profile verification details, joined date, contact info updated date, and profile photo updated date. This helps distinguish from sibling tools like get_public_profile_data which likely returns broader public data, though it doesn't explicitly differentiate 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 provided on when to use this tool versus the many other profile-related tools (e.g., get_profile_data_and_connection_u0026_follower_count, get_public_profile_data). There are no usage contexts or exclusions mentioned.
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; description only states 'Get article with url'. Fails to mention whether it is read-only, requires authentication, or any 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?
Extremely concise at 4 words, front-loaded. However, could be slightly more informative without losing conciseness.
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 with one parameter and no output schema, but lacks behavioral context that would help an agent understand prerequisites or usage patterns.
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 'url' parameter has 100% schema coverage with an example. 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?
Clear verb 'Get' and resource 'article'. Distinguishes from siblings like 'get_post' or 'get_company_details', but lacks explicit scope or differentiation 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 (e.g., get_article_comments, get_user_articles). 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 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?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'get' but does not reveal any behavioral traits such as authentication requirements, rate limits, or whether the operation is read-only. The description fails to add context beyond the obvious.
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 with no extraneous words. It efficiently communicates the core purpose despite being 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?
Given the presence of many sibling tools and no output schema, the description is incomplete. It does not explain the return structure, pagination, sorting behavior, or any constraints like required permissions. This lack of detail hinders an agent from using the tool effectively.
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%: each parameter has an example value in the schema. The description adds no additional meaning beyond the schema. Baseline 3 is appropriate since the schema already documents the parameters sufficiently.
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 comments with url' clearly states a specific verb and resource: retrieving comments from an article. It distinguishes itself from sibling tools like get_article (which gets the article itself) and get_article_reactions (which gets 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 is provided on when to use this tool versus alternatives (e.g., get_post_comments for posts, get_profiles_comments for profiles). There is no mention of prerequisites, exclusions, or context where this tool is preferred.
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?
With no annotations, the description must disclose behavior. It only states the action, omitting details like read-only nature, pagination handling (despite a page parameter), or any 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?
While very short, the description sacrifices necessary detail for brevity. It is under-specified, lacking critical instructions for effective use.
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, the description should explain return values and differentiate from similar tools (e.g., get_post_reactions). It fails to do so, 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?
Schema coverage is 100% with examples. The description adds no meaningful information beyond the schema, only restating 'with url'. Baseline score 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 reactions) with a key input (url). However, it does not differentiate from sibling tools like get_post_reactions or get_article, which could 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_post_reactions or get_article. The description lacks context for decision-making.
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?
The description mentions a credit cost ('1 credit per successful request'), which is a behavioral trait. However, it does not disclose whether the tool is read-only, requires authentication, or has any side effects. With no annotations, the description carries full burden and 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?
The description is very concise with one sentence plus a bolded cost note. It is efficient but lacks detail; it could benefit from more context without being 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 the simple tool (one required parameter, no output schema), the description is incomplete. It does not explain what data is returned, how 'enrich' works, or how to properly specify the domain. The credit cost is noted, but overall context is lacking.
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% (one parameter with example). The description adds little beyond the schema, mentioning 'by domain' but not clarifying the format or constraints. Baseline 3 is appropriate as the schema already covers the 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 'Enrich the company data by domain', which indicates the tool returns company data based on a domain. However, the verb 'enrich' is ambiguous and does not clearly differentiate from sibling tools like get_company_details or get_company_details_by_id, which likely serve similar purposes.
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 sibling tools include various company detail tools, but the description does not specify contexts or exclusions, leaving the agent to infer usage.
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 provided, so the description should disclose behavioral traits like read-only nature, permissions, rate limits, or response structure. The description only says 'enrich', which is unclear, and fails to clarify that this is a read operation or any safety profile.
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, which is concise, but it is grammatically awkward ('The endpoint enrich...') and lacks structure. It could be improved for clarity without adding 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 abundance of sibling tools and the absence of an output schema, the description should provide more context about the nature of the returned 'full details' and how this tool fits into the overall API. It is insufficiently complete for an agent to correctly select and invoke this 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?
The input schema has 100% description coverage with a simple example, but the tool description does not add meaning beyond the schema. The parameter 'username' is not explained further, and the description does not clarify what kind of identifier 'username' is (e.g., company LinkedIn username) or how it relates to other tools accepting domain or ID.
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 full details of the company', giving a general idea of returning comprehensive information, but the verb 'enrich' is vague and the purpose is not clearly specified compared to sibling tools like 'get_company_employees_count' or 'get_company_insights_premium'.
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. With multiple company-related tools (e.g., by domain, by ID), there is no indication of the appropriate context for using 'username'.
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?
No annotations are provided, so the description must disclose behavioral traits. The term 'enrich' could imply a write operation, which contradicts the read-only intent of a 'get' tool. No clarity on idempotency, side effects, or authorization needs.
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 one sentence, but it is poorly worded and uses 'enrich' incorrectly. While brevity is good, clarity is sacrificed. A more straightforward phrasing like 'Retrieves full details of a company by its unique ID' would be better.
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 is provided, so the description should hint at what 'full details' includes. It does not. Given many sibling tools, it fails to clarify overlap or data uniqueness. Completeness is insufficient for a retrieval 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% (the single 'id' parameter is described in the schema). The description adds no additional meaning about the parameter format, constraints, or relationship to other tools. 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 says 'enrich full details', which is vague and grammatically poor. The tool name 'get_company_details_by_id' already clearly states the purpose, so the description adds little value. It does not effectively differentiate from siblings like 'get_company_by_domain' 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 is provided on when to use this tool versus alternatives. There are many sibling tools for company data (e.g., by domain, insights, employees count) but the description offers no usage 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 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, so the description carries the burden. 'Get' implies a read operation, but the description mentions a location filter with no corresponding parameter, which is confusing and potentially misleading about the tool's actual 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 a single sentence, which is concise, but it omits critical details such as how the company is specified (maybe via context?). It could be restructured to clarify the contradiction about 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 and no annotations, the description is incomplete. It does not explain how to specify the company (e.g., via domain, ID), nor does it resolve the location filter paradox. A more complete description would address these 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?
The input schema has zero parameters, yet the description claims a location filter is possible. This contradiction means the description adds no meaningful semantic value and actively misleads.
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 company employees count' which is a clear verb+resource, but it's vague because it doesn't specify which company or how the company is identified. The parenthetical '(location filter possible)' adds ambiguity since the input schema has no parameters.
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 siblings like get_company_details or get_company_insights_premium. No exclusions or prerequisites mentioned.
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?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without any details about side effects, permissions, rate limits, or what the tool returns. The emptiness of the input schema also raises unaddressed questions about implicit dependencies.
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 (3 words), but this is under-specification rather than conciseness. It lacks essential context and structure, such as clarifying the scope or output, making it unhelpful for an AI 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 lack of annotations, empty input schema, and no output schema, the description is severely incomplete. It does not explain what information is returned, how the company is identified, or how this tool fits with the multitude of sibling tools. The agent would have no way to use this tool correctly based solely on this definition.
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 no parameters in the input schema, and the description adds no value beyond that. However, the absence of parameters is peculiar (how does the tool know which company?), and the description fails to explain how the company is determined, which is a critical semantic gap.
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 jobs' clearly indicates the action (get) and resource (company jobs), but it lacks specificity about what 'company jobs' entails (e.g., listing all jobs, job details?). It does not differentiate from sibling tools like get_company_jobs_count or search_jobs, especially since the input schema is empty, leaving ambiguity about how the company is identified.
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 usage guidance is provided. The description does not indicate when to use this tool versus alternatives like search_jobs, get_company_details, or get_company_jobs_count. It also fails to mention any prerequisites or context for invocation.
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?
Without annotations, the description carries the full burden. It clarifies it returns a count of 'opening jobs', but does not mention any behavioral traits such as rate limits, permissions, or response format. For a simple read operation, this is adequate but lacks depth.
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, direct sentence with no filler or redundancy. 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?
Given the tool's simplicity (one parameter, no output schema) and the presence of many sibling tools, the description is minimally complete but could mention the return type (e.g., integer) to fully inform the 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?
Schema coverage is 100% with the parameter 'companyId' described (example value). The description adds no extra parameter semantics beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'total number of opening jobs', distinguishing it from sibling tools like 'get_company_jobs' (which likely returns a list) and 'get_company_employees_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 provided on when to use this tool versus alternatives, nor any context about prerequisites or exclusion criteria. The agent must infer use cases from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
Discloses pagination behavior and the presence of a total count in responses. Does not mention error handling, rate limits, or consequences of invalid input. With no annotations, the description carries full burden but remains incomplete.
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 conveying purpose and usage. However, it is somewhat run-on and could be split for clarity. Front-loaded with action but slightly 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?
No output schema exists, so description should explain the response structure. It only mentions 'total recommendations count' but omits details about returned data, fields, or error formats. Insufficient for an agent to parse results.
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 example values. The description adds context on how to use the 'start' parameter for pagination, but does not clarify data types or constraints beyond the schema examples.
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 scrapes recommendations from a profile and explains pagination. However, it does not explicitly differentiate from sibling 'get_received_recommendations', which might imply a different direction of recommendations.
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 specific pagination instructions on how to iterate through results. However, it lacks guidance on when not to use this tool or mention of alternative methods, such as using 'get_received_recommendations' if the direction varies.
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 the burden. It indicates a read operation via 'Get', but does not disclose side effects, permissions, or error handling. Basic but not exhaustive.
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 redundancy, conveying all necessary information efficiently.
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?
While the tool is simple, the description lacks any indication of the output format or content (e.g., does it return team members or just poster?). With no output schema, this omission reduces 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%, but the description adds crucial constraint that one of the two parameters is required, which the schema's empty required array does not convey. This adds meaningful guidance.
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 that the tool retrieves details about the hiring team or job poster for a job, distinguishing it from sibling tools like get_job_details 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?
It explicitly states that a job id or url is required, providing clear context for use. However, it does not exclude alternatives or specify when to use this tool over other profile-related tools.
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 exist, and the description does not disclose behavioral traits like whether the operation is read-only, any side effects, rate limits, or authentication requirements.
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 appropriately concise with a single sentence, but it could be slightly more informative without being 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?
For a tool with one parameter and no output schema, the description is adequate but lacks detail on return value or edge cases; context from sibling tools suggests it's specialized but not clarified.
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 description does not explain the 'url' parameter beyond the schema's example URL, but schema coverage is 100%, meeting the baseline; however, no additional value is added.
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 post details' indicates the tool retrieves post information, but it does not specify what type of post (e.g., LinkedIn feed post vs. article) or distinguish it from similar sibling tools like get_article or get_companys_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 over alternatives; lacks context about prerequisites, filtering, or comparison with siblings such as get_article or get_post_reactions.
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?
No annotations exist, and the description fails to disclose behavioral traits such as implicit input (how it identifies the post), return format, pagination, or rate limits. The agent cannot infer the tool's behavior beyond the minimal 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?
Single sentence is concise but too vague. It omits critical context, making it insufficient for agent use.
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, the description should clarify what 'profiles' means (IDs, full data) and how the post is identified. It is incomplete for practical use.
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, so schema coverage is 100%. The description does not add value beyond the schema, missing the opportunity to explain implicit context (e.g., needing a prior post ID from a different tool). Baseline for 0 params is 4, but lack of clarity reduces it.
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 gets profiles that reacted to the post, using a specific verb and resource. It distinguishes from siblings like 'get_post_reposts' and '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 or alternatives. The description does not mention any prerequisites or context, leaving the agent uncertain about how to invoke the tool.
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 provided, so description carries full burden. It discloses it's a read operation but does not mention return format, pagination, or rate limits. The phrase 'by post url' suggests a parameter that is not in the schema, creating confusion.
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 redundancy or wasted 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 no output schema and zero parameters, the description is too minimal. It does not explain what reposts are, how the post URL is specified (if at all), or what the output contains. The sibling tools provide richer context, but this description falls short.
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, yet the description implies a 'post url' parameter. This mismatch is misleading. Schema coverage is vacuously 100%, but the description adds false expectations.
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), the resource (post reposts), and the method (by post url). It distinguishes from siblings like get_post (which retrieves the post itself) and get_post_reactions (which retrieves 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 vs alternatives. Given many sibling tools for posts, explicit usage context would help but is missing.
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?
With no annotations, the description carries the burden of disclosing behavior. It mentions a pagination limit of 50 results per page but does not specify if pagination is supported or how to access additional pages. There is no mention of read-only nature, authorization needs, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and includes a key detail (50 results per page). Every word is necessary; no waste.
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), the description is adequate but not complete. It fails to describe the return format or pagination details. An agent would not know the structure of the response or how to handle multiple pages.
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 schema description coverage is 100%. The description cannot add meaning beyond this. A score of 4 is the baseline for zero parameters, as there is nothing to explain.
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 the profile's company interests' which is a specific verb and resource. It also mentions a limit of 50 results per page, differentiating it from other profile interest 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 explicit guidance on when to use this tool versus alternatives. The description implies it is for retrieving company interests, but lacks context on prerequisites, limitations, or when not to use it. Without details, it's minimally adequate.
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 provided and the description does not disclose any behavioral traits (e.g., read-only nature, rate limits, or side effects). It merely restates 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?
While short, the description is a single phrase that lacks structure and essential information. It is under-specified rather than appropriately 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?
Without output schema or annotations, the description should explain return format or behavior. It does not, leaving the tool's output completely undefined.
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 provides an example value for 'username' but no true description. The tool description adds no additional meaning beyond the schema, which already covers the 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 is a tautology, restating the tool name without adding specificity. It fails to distinguish from similar sibling tools 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 on when to use this tool versus siblings or any context about prerequisites. The description is entirely absent of usage instructions.
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 exist, and the description does not disclose any behavioral traits such as read-only nature, potential rate limits, or data scope.
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 but is a tautology, offering no value. 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 large number of sibling tools, the lack of output schema, and no annotations, the description is completely inadequate for an agent to understand what the tool does or when to invoke 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?
The schema covers the single parameter with an example but lacks semantic detail; the description adds no further meaning about the parameter's purpose or constraints.
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 merely restates the tool name without specifying what data is retrieved or how it differs from siblings like 'get_profile_connection_u0026_follower_count' and 'get_profile_data_connection_u0026_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 guidance on when to use this tool versus any of the many similar profile-related tools is provided.
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 are provided, so the description carries the burden. It adds the credit cost (2 credits per call) which is useful, but does not disclose other behavioral traits like read-only/destructive nature, rate limits, or side effects. The cost information is positive but insufficient for full transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence and includes essential credit cost information. However, it could be slightly more structured with bullet points or clearer separation of features.
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 many sibling tools and lack of output schema, the description is too minimal. It doesn't explain what specific profile data is retrieved, the format of posts, or pagination, leaving significant gaps for the agent to use the tool effectively.
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 'username' described by an example. The description does not add any additional meaning or constraints beyond the schema, so baseline 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 clearly states the tool gets profile data, connection & follower count, and posts. However, it does not differentiate from similar sibling tools like 'get_profile_data_and_connection_u0026_follower_count' or 'get_profile_connection_u0026_follower_count', which likely overlap.
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. The description does not mention prerequisites, contexts, or exclusions, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 are provided. The description discloses the pagination limit of 50 results per page. It does not mention authentication requirements, whether the operation is read-only, or any side effects. The description adds some behavioral context but not enough.
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 directly states the tool's purpose and a key constraint (result limit). No superfluous words; efficient and 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?
The tool is simple with no parameters and no output schema, so the description is somewhat complete. However, it lacks context about whose profile is being queried (e.g., the authenticated user's profile or a specified one). This could lead to incorrect assumptions about 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?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter details. It mentions 'up to 50 results per page', which could be interpreted as an implicit parameter, but no parameters exist. Baseline for zero parameters is high, though the mention might cause confusion.
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 verb 'get' and resource 'profile's group interests' with a pagination limit. Differentiates from sibling tools like 'get_profile_company_interest' and 'get_profile_school_interests'. However, it does not specify which profile (e.g., current user or arbitrary), leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. Among sibling tools, there are other 'get_profile_*_interests' tools, but the description provides no criteria for choosing one over the other.
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 partially fills the gap by mentioning 'up to 50 results per page', implying pagination and a read operation. However, it doesn't disclose whether it returns all interests, error cases, or authentication needs.
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 concise sentence that front-loads the action and scope with no wasted 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?
For a simple zero-parameter tool, the description covers the core action and pagination limit. It lacks details on which profile is assumed (e.g., authenticated user) and how to navigate pages, but these are reasonable omissions given the tool's simplicity.
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 100% coverage, so the description doesn't need to add parameter details. It appropriately omits param info, which is fine here.
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 newsletter interests', and the pagination detail helps distinguish it from other interest-related tools like get_profile_company_interest or get_profile_group_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?
The description provides no guidance on when to use this tool versus alternatives like get_profile_company_interest or how to handle pagination (e.g., page parameter). It only states what it does, not the context.
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 present, yet the description fails to disclose behavioral traits such as read-only nature, authentication needs, or what the output contains. The word 'get' implies a read operation, but this is minimal and falls short of adequate 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 sentence of 5 words, but it is a tautology with no informative content. It is concise but not valuable, earning a low score for failing to use its brevity 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?
Given the lack of annotations and output schema, the description should compensate by explaining what the tool returns, how it differs from siblings, and any behavioral details. It does none of this, leaving the agent with no actionable 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?
Despite 100% schema description coverage, the description adds no meaning beyond the input schema. The parameter 'username' is only illustrated with an example in the schema, and the description does not clarify its role or format. The baseline of 3 for high coverage is not justified because the description adds zero parameter-specific insight.
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 that repeats the tool name without specifying what 'positions with skills' means or how they differ from other profile data. It does not help distinguish from siblings like get_profile_data_connection_u0026_follower_count_and_pos or get_public_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 compared to the many other profile-related siblings. There is no mention of prerequisites, limitations, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, the description carries full burden. It states 'Get', implying a read-only operation, but does not disclose behavioral traits like required permissions, error handling for invalid URNs, or response format. The tool is simple, so this minimal disclosure is acceptable but not exemplary.
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 with no wasted words. It could be slightly improved for clarity (e.g., 'Get a profile post and its comments'), but it is very 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?
For a simple read tool with one parameter and no output schema, the description is minimally adequate. It covers the purpose but lacks context on return structure or pagination (if any). Given the complexity, it is acceptable but not fully complete.
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 for 'urn' (URL and URN format). The description adds no further meaning beyond the schema; baseline 3 is appropriate as the schema does the heavy lifting.
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 both a post and its comments ('Get profile post and comments of the post'). It uses a specific verb (Get) and resource (profile post and comments), distinguishing it from siblings like 'get_post' (only post) or 'get_profile_post_comment' (single 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 explicit guidance on when to use this tool vs alternatives such as 'get_post' or 'get_article_comments'. The description implies it provides combined data, but doesn't mention when it's preferable to use separate sibling tools or any prerequisites.
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, and the description does not disclose any behavioral traits such as side effects, data freshness, rate limits, or authentication requirements. The description is too minimal to inform safe usage.
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 and to the point, with no wasted words. It is front-loaded with the action and resource. However, it could be slightly expanded to include usage context without losing conciseness.
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 complexity of the tool (pagination parameters), the description does not provide enough context about what is returned or how pagination works. It is incomplete for effective use.
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 already describes parameters well. However, the tool description adds no additional meaning beyond what is in the schema; it does not explain how the parameters relate to the tool's purpose.
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 'Find out what posts a profile reacted to' clearly states the tool's action (find) and resource (posts a profile reacted to). It distinguishes from siblings like 'get_post_reactions' which likely retrieves reactions to a post, and 'get_profile_reactions' is unique among 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 such as 'get_profile_posts' or 'get_post_reactions'. There are no prerequisites or constraints mentioned.
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; description only indicates a read operation ('Get the time') without disclosing additional traits like authentication requirements, rate limits, or definition of 'last activity'.
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 extraneous words; 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?
For a simple tool with one parameter and no output schema, the description is minimally sufficient but lacks detail on return format or activity scope.
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 for 'username'; 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 explicitly states the verb 'Get' and the resource 'time of the profile's last activity', making the tool's purpose clear and distinct 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 on when to use or not use this tool vs alternatives; usage is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, the description must disclose behavioral traits. It reveals pagination ('up to 50 results per page'), which is valuable. However, it omits whether the operation is read-only, requires authentication, or what happens if no interests exist. The description adds some transparency but could be richer.
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 immediately conveys the tool's purpose and key constraint (50 results per page). No unnecessary words, front-loaded 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?
Given zero parameters and no output schema, the description partially fills the gap by stating the result limit, but lacks details on output structure, pagination mechanism, or implicit profile context. An agent may need more information to use the tool confidently.
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 coverage is 100%. The description adds meaning by indicating the result count and pagination behavior, which goes beyond the schema. It compensates for the lack of param detail with useful functional context.
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's school interests' with a specific resource and action. The mention of 'up to 50 results per page' distinguishes it from other similar tools by indicating pagination behavior, and it is unambiguous among sibling tools like get_profile_company_interest.
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_profile_group_interests or other interest tools. It does not specify prerequisites, context, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
The description discloses that the tool returns the last 50 comments and costs 1 credit. It does not state whether it is read-only (likely but not explicit), or address rate limits or pagination. With no annotations, the description provides moderate transparency but could be more thorough.
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 two sentences, front-loaded with the core purpose and cost. Every word is necessary, with no redundancy or filler.
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 covers the essential information (what it does, count, cost). However, the ambiguity of 'comments of a profile' slightly detracts from 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 description for 'username' that provides an example value. The tool description does not add further semantics about the purpose or format of the parameter, so it meets the baseline but does not exceed it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'last 50 comments of a profile'. It includes the cost per call. However, it is ambiguous whether these are comments made by the profile or on the profile's content, and it does not distinguish from sibling tools like get_profile_post_comment or get_article_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 alternatives. Among siblings, there are many comment-related tools, but 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 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?
With no annotations, the description must disclose behavioral traits. It does not mention authentication requirements, rate limits, or what constitutes a 'posted job' (e.g., does it include reposts or only original job posts?). The return format is also unspecified.
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 one sentence with no unnecessary words. It is 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?
Given no output schema, 36 sibling tools, and potential ambiguity (what are 'posted jobs'?), the description is insufficient. It lacks details on how to use the username parameter correctly, what the response looks like, and how this tool differs from other job-related tools (e.g., 'get_company_jobs', 'search_jobs').
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 parameter 'username' is described in the schema as 'LinkedIn job id', which is contradictory and misleading. The description fails to clarify this inconsistency, leaving the agent confused about whether to provide a username or a job ID. Since schema coverage is 100% but the schema description is incorrect, the description should compensate but does 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 'Get profile's posted jobs' clearly states the action (Get) and the resource (profile's posted jobs). It distinguishes from sibling tools like 'get_profiles_posts' (which likely returns all posts) and job-specific tools like 'get_company_jobs' (company-centric).
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_profiles_posts', 'get_job_details'). There is no context on prerequisites, such as requiring a LinkedIn profile username, or when to choose this over other job retrieval tools.
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?
No annotations are provided, and the description only mentions a credit cost. It does not disclose whether the operation is read-only, any side effects, or rate limits. There is no information 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 extremely concise: two sentences that convey the core purpose and cost. No unnecessary words or 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?
Given the tool has pagination (start, paginationToken) and no output schema, the description lacks details about how to use pagination, the response format, error handling, or any prerequisites. It is insufficient for a tool with 4 parameters.
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; it merely restates the tool's purpose. Parameters are well-documented in the schema itself.
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 explicitly states the verb 'Get', the resource 'last 50 posts of a profile', and the limit '50 posts', making it clear and distinct from siblings like get_article 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 is given on when to use this tool versus alternatives such as get_profile_post_and_comments or search_posts. The pagination parameters are described in the schema but no usage context is provided.
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 provided, and the description does not disclose behavioral traits like read-only nature, required permissions, or response format. For a tool with zero annotations, 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?
Extremely concise single sentence. While it could benefit from more detail, it is not verbose and gets the main point across efficiently.
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 no annotations, the description is too brief. It does not explain what 'top voices interests' are, how to interpret the result, or provide any usage context, making it incomplete 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?
There are zero parameters, and schema coverage is 100%. The description adds no parameter info, but with no parameters, the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves top voices interests for a profile. It distinguishes from siblings like get_profile_group_interests or get_profile_newsletter_interests, but lacks specification of which profile (likely the current user's).
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 get_profile_group_interests or get_public_profile_data. The description does not mention any prerequisites or exclusions.
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. The description does not disclose behavioral traits such as rate limits, data freshness, or handling of invalid URLs, leaving the agent without critical 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 a single, clear sentence. It is concise but could benefit from additional context without being 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?
No output schema exists, and the description omits details about the return format (e.g., list of URLs, IDs, or full profiles). Incomplete for an agent to use effectively.
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 covers 100% of the single parameter with an example, so the description adds little extra meaning. 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 tool returns similar profiles given a profile URL, which is specific and distinct from many siblings. However, it does not specify the source (LinkedIn) or define criteria for similarity.
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 search_people or get_public_profile_data. No exclusions or prerequisites mentioned.
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, the description carries full burden for behavioral disclosure. 'Health Check' reveals nothing about side effects, required permissions, or return 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 concise but reduces to under-specification. It does not convey useful information beyond 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?
Even for a tool with no parameters and no output schema, the description must clarify the tool's function. A single phrase repeating the name is wholly inadequate.
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 there are no parameters, the description adds zero meaning beyond the empty schema. Baseline of 4 is not applicable because the description is uninformative.
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 merely restates the tool name. It fails to specify what is being checked (e.g., server, API, database) or what the tool actually does.
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 the numerous sibling tools. The description lacks any 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 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 carries the full burden. It only states the action and cost, without disclosing behavioral traits like authentication needs, rate limits, or 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?
Two sentences with no wasted words: first sentence defines purpose, second states cost. It is concise but could be more structured.
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 description of return values. The tool combines profile data and recommendations but does not explain the structure or fields returned, leaving the agent with insufficient 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% with a single 'username' parameter and example value. The description adds no additional meaning 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?
Description clearly states 'Get Profile Data, Given and Received Recommendations', which is a specific verb-resource combination. This distinguishes it from sibling tools like 'get_given_recommendations' and 'get_received_recommendations' by combining both functionalities.
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. For example, if only profile data or only recommendations are needed, separate tools exist, but the description does not mention these conditions or exclusions.
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?
With no annotations present, the description carries the full burden of disclosing behavioral traits. It provides no information about read-only nature, authentication, rate limits, or return format. The agent has no insight into what the tool does beyond a vague search.
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?
While extremely concise (two words), it is under-specified. The sentence does not earn its place because it adds no value beyond the tool name, resulting in insufficient guidance for 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 lack of parameters, output schema, and annotations, the description is grossly incomplete. It provides no context about how to formulate a search or what to expect as a response, making it inadequate for a search 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?
The input schema has zero parameters, so schema coverage is 100%. Per guidelines, baseline is 3. The description adds no additional meaning beyond the schema, but it doesn't detract either.
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 companies' is a tautology of the tool name 'search_companies', adding no additional meaning. It fails to specify the scope, criteria, or how it differs 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 is provided on when to use this tool versus alternatives. Sibling tools include many search variants, but the description offers no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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?
With no annotations, the description carries full burden for behavioral disclosure. It states nothing about outputs, side effects, authentication needs, or pagination, which is critical for a search tool with 13 parameters.
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 overly terse at the expense of informativeness. Conciseness should not sacrifice necessary details; here it provides zero actionable 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's complexity (13 parameters, no output schema, no annotations), the description is completely inadequate. It does not address common user concerns like filtering behavior, result limits, or error handling.
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 what the schema already provides. Many parameter descriptions in the schema are vague (e.g., 'please follow this link'), and the tool description fails to clarify or summarize usage patterns.
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, restating the tool name without adding any specific verb or resource scope. It fails to distinguish from sibling tools like 'search_jobs_v2' 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. There is no mention of use cases, prerequisites, or exclusions, leaving the agent with no decision support.
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 exist, so description must disclose behavior. It only says 'Search Jobs' without indicating read-only, destructive potential, rate limits, or any side effects. Completely 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?
Extremely short (2 words) but fails to convey essential information. Conciseness should not sacrifice clarity; this is under-specification.
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 14 parameters, no output schema, and no annotations, the description is severely incomplete. Does not explain return format, pagination, or how to use complex parameters like locationId.
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 the description adds zero meaning beyond schema. Parameter descriptions like 'please follow this link' are vague and unhelpful.
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 Jobs' which is a verb+noun but overly generic. It does not differentiate from other search tools like 'search_jobs' or 'get_job_details'. Lacks specifics about scope or results.
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 sibling search tools. No mention of prerequisites or context (e.g., job searching on LinkedIn).
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?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states that it searches by keyword, with no information about result format, pagination, rate limits, or any 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 short (one sentence) and directly communicates the core function. It is concise with no waste, though it could be slightly more informative 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 the tool's simplicity (single param, no output schema), the description is minimally adequate. However, it lacks any context about the scope of locations, result size, or how results are returned, which would be helpful 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?
The schema has 100% coverage with a single required parameter ('keyword') and an example value. The description adds minimal value beyond the schema by stating 'by keyword', which is already evident. 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 tool searches locations by keyword, using a specific verb ('search') and resource ('locations'). It is distinct from sibling tools that focus on profiles, companies, or jobs, but does not explicitly differentiate 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 provided on when to use this tool versus alternatives (e.g., other search tools for companies, jobs, or people). There is no mention of when not to use it or any prerequisites.
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?
With no annotations, the description must disclose behavior. It notes that results may be fewer than 10 per page due to automatic filtering of hidden profiles. However, it does not mention auth requirements, rate limits, or what happens with empty results, and the wording is confusing.
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 but grammatically poor and awkward (e.g., 'not return all profiles as public'). It lacks clear structure and wastes space on unclear phrasing.
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 9 optional parameters, no output schema, and no annotations, the description should explain pagination, parameter interactions, and result format. It only addresses one minor behavioral nuance and leaves major 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?
Schema coverage is 100%, but the schema descriptions are minimal (e.g., 'Example value: max' for keywords). The tool description adds no additional parameter guidance. For a parameter-heavy tool, this is insufficient.
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 'Search profiles by a keyword', which clearly identifies the core function. However, it does not differentiate from sibling tools like 'search_people_by_url' or 'get_public_profile_data', and it omits the return type (list of profiles).
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. The description mentions pagination and hidden profiles but does not explain contexts or exclusions (e.g., when to use search_people_by_url instead).
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?
Discloses that some profiles are hidden and automatically filtered, causing fewer results. However, no annotations provided, and description does not cover other behavioral aspects like data freshness or authorization.
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 is too brief but poorly worded with grammatical errors ('This is because not return all profiles as public'). Lacks clarity and structure.
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, and no explanation of URL-related functionality. Does not specify what 'keyword' refers to or how filtering works. Incomplete for a tool with no parameters.
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 mentions 'by a keyword' implying a parameter. This is misleading. Baseline for 0 params is 4, but contradiction reduces 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?
Describes searching profiles by keyword, but tool name 'search_people_by_url' suggests URL-based search. Contradiction between name and description. Does not differentiate 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 explicit guidance on when to use this tool vs alternatives like 'search_people' or 'get_public_profile_data_by_url'. Only mentions pagination issue without 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 behavioral traits are disclosed. The description does not indicate whether the operation is read-only, destructive, or any side effects. Without annotations, the description carries the full burden but fails to provide any 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 short, but it lacks the information needed to be useful. 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 empty schema and no annotations, the description is completely inadequate. It does not explain how to invoke the tool or what to expect in return.
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 is empty, yet the tool's purpose implies a hashtag parameter. The description does not clarify how to provide the hashtag, leaving the agent unable to determine correct 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 'Search Post by Hashtag' clearly states the action and resource, but it is essentially a restatement of the tool name with no additional context about how the hashtag is specified or what results are returned.
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 usage guidelines are provided. There is no indication of when to use this tool versus sibling tools like 'search_posts' or how to specify the hashtag.
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 carries full burden for behavioral transparency. It only states 'Search Posts' without revealing safety, authentication, rate limits, or what happens (e.g., returns list of posts). Insufficient for a search 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?
Extremely concise but under-specified. The single phrase fails to convey any actionable information, missing a valuable opportunity to describe the tool's functionality.
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?
Lacking any context on output, filtering, or behavior. With no output schema or annotations, the description should compensate but fails to, making it incomplete for an agent to use effectively.
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 (100% coverage by default). Baseline is 4, but the description adds no meaning beyond the tool name. It doesn't clarify how the search works without parameters, so by formula it gets 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?
Description 'Search Posts' is extremely vague. It doesn't specify the source or scope of posts, nor does it differentiate from sibling tools like 'search_post_by_hashtag' or other search tools, making it hard for an agent to select correctly.
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 usage guidance provided. The description gives no indication of when to use this tool versus alternatives such as search_companies or search_jobs, nor any prerequisites or constraints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0about_the_profileget_articleget_article_commentsget_article_reactionsget_company_by_domainget_company_detailsget_company_details_by_idget_company_employees_countget_company_insights_premiumget_company_jobsget_company_jobs_countget_company_pages_people_also_viewedget_company_post_commentsget_companys_postget_given_recommendationsget_hiring_teamget_job_detailsget_postget_post_reactionsget_post_repostsget_profile_company_interestget_profile_connection_u0026_follower_countget_profile_dataget_profile_data_and_connection_u0026_follower_countget_profile_data_by_urlget_profile_data_connection_u0026_follower_count_and_posget_profile_group_interestsget_profile_newsletter_interestsget_profile_positions_with_skillsget_profile_post_and_commentsget_profile_post_commentget_profile_reactionsget_profile_recent_activity_timeget_profile_school_interestsget_profile_top_positionget_profile_top_voice_interestsget_profiles_commentsget_profiles_posted_jobsget_profiles_postsget_received_recommendationsget_similar_profilesget_user_articleshealth_checkprofile_data_u0026_recommendationssearch_companiessearch_jobssearch_jobs_v2search_locationssearch_peoplesearch_people_by_urlsearch_post_by_hashtagsearch_postsScored across 52 tools
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.
LinkedIn: The LinkedIn Data API offers access to detailed information on individuals, companies.
LinkedIn data for AI agents: profiles, companies, jobs, posts, search. Sales research, recruiting.
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.
