LinkedIn MCP Server

by oliverhruby

Overview Schema Source Related Servers Discussions Admin

Python

Local

list_accessible_organizations

Retrieve organizations where the authenticated user has admin-like roles.

Instructions

List organizations where current user has admin-like roles.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_accessible_organizations"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No		/v2/organizationAcls

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Sep 5, 2026

TDQS

C2.8/5.0

Behavior2/5

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. It states the tool 'lists' organizations and mentions 'admin-like roles,' but does not clarify whether authentication is required, what 'accessible' entails, whether the operation is read-only, or how it handles the single path parameter.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that states the core purpose immediately. It wastes no words, though its brevity contributes to the lack of behavioral and usage detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple and an output schema exists, so return values are covered. However, the description omits behavioral context such as auth requirements, the role semantics, and the meaning of the path parameter. It is minimally complete but lacks helpful guidance for an agent operating in a larger tool suite.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one optional parameter 'path' with a default value, and description coverage is 0%. The description does not explain the purpose of the path parameter or whether it should ever be changed, leaving the agent without meaningful guidance beyond the default value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'List' and resource 'organizations', and qualifies with 'where current user has admin-like roles,' clarifying that it returns organizations the user can access. It is distinct from sibling tools like list_campaigns or auth tools, though it does not explicitly name an alternative.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance is given about when to use this tool versus alternatives, nor any exclusions or prerequisites. The intended use is implied by the name and description, but the agent is left to infer that it should be used after authentication and when organization-level access is needed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.