linkedin_company_getGet a LinkedIn company page by company URL — use linkedin.organization.get for schools and mixed organization URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | LinkedIn company page URL for this lookup. School and organization-guest pages are not supported; use `GET /v1/linkedin/organizations`. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as readOnlyHint and openWorldHint, covering its safety and return variability. The description adds the behavioral constraint that school and organization-guest pages are unsupported, which is useful context beyond the annotations but does not detail error behavior or response structure. Given the annotation coverage, this is solid 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, front-loaded sentence that states the primary action and immediately provides the efficient routing hint to the alternative tool. Every word serves a purpose, and there is no redundancy.
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 one-parameter, read-only tool with full schema coverage and no output schema, the description conveys all necessary information: what the tool does, the URL parameter, the exclusion of certain URL types, and the alternative tool when needed. No critical detail is missing 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?
The schema describes the url parameter with 'LinkedIn company page URL for this lookup. School and organization-guest pages are not supported; use `GET /v1/linkedin/organizations`.' This covers meaning and constraints. The description merely restates 'by company URL' without adding format examples or further syntax details, so it stays at the baseline for full schema coverage.
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 performs a GET operation on a LinkedIn company page, identified by URL. It differentiates itself from the sibling linkedin_organization_get by explicitly naming the alternative for schools and mixed organization URLs, leaving no ambiguity about its specific target resource.
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?
Usage guidance is explicit: it states that for schools and mixed organization URLs, one should use linkedin.organization.get instead. The parameter description reinforces this by noting these URL types are not supported, giving clear exclusions and pointing to the correct alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool is clearly scoped to a specific platform and action (e.g., facebook_post_get vs instagram_post_get). Descriptions explicitly differentiate similar tools across platforms, and within-a-platform tools like tiktok_search_videos_list vs tiktok_search_hashtag_list have clear disambiguation notes.
All 167 tools follow a strict `platform_resource_action` pattern (e.g., youtube_video_comments_list). No mixing of styles—snake_case throughout, with consistent verb ordering (get, list, search, etc.).
The server has 167 tools, which is far beyond the typical well-scoped range of 3-15. While the broad multi-platform scope justifies many tools, this extreme number makes the tool surface overwhelming and difficult for an agent to navigate efficiently.
The tool set covers a wide range of platforms and operations including profile retrieval, post/video fetching, comments, search, transcripts, and ad library access. Minor gaps exist (e.g., no Facebook events or LinkedIn messaging), but the surface is comprehensive for a read-only data aggregation use case.