Skip to main content
Glama
LinkedIn Copilot MCP

LinkedIn Copilot MCP

by Kian-hdr

crm_search_people

Read-onlyIdempotent

Search private LinkedIn channel indexes and company CRM master records to find people without loading your inbox. Supports contact lookup and company matching.

Instructions

Search private LinkedIn channel indexes without loading the inbox; use the external company CRM native search for company master records.

Input Schema

NameRequiredDescriptionDefault
limitNo
queryNo
offsetNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that the search avoids loading the inbox and operates over private LinkedIn channel indexes, which is useful context, but it does not disclose return format, pagination behavior, or permission requirements.

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 front-loaded sentence with no obvious filler. Its semicolon clause is somewhat awkward, but the overall length is appropriate for the tool.

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

Completeness2/5

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

For a search tool with three optional parameters, no output schema, and 0% schema description coverage, the description is too thin. It does not explain what is returned, how results are paginated, or what distinguishes the searchable indexes.

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?

Schema coverage is 0%, so the description must explain query, limit, and offset semantics. It only implies a query through the word "Search" and says nothing about limit or offset, leaving two of three parameters undocumented.

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

Purpose3/5

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

The description gives a verb and an unusual resource ("private LinkedIn channel indexes"), but it does not clearly say it searches people even though the tool name is crm_search_people. It does distinguish itself from searching company master records, but the core resource remains ambiguous.

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

Usage Guidelines3/5

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

It hints at when not to use this tool by saying it works "without loading the inbox" and by pointing company master record searches to the external CRM native search. However, it does not explicitly state when this tool should be chosen over sibling tools like crm_list_entities or linkedin_get_inbox_page.

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