Multilead Open API MCP Server

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

With no annotations provided, the description carries full burden. It discloses the action's purpose and outcome ('retrieves all LinkedIn messages', 'displays them inside the platform's inbox'), but doesn't mention behavioral traits like whether this is a one-time sync or continuous, potential rate limits, authentication requirements beyond the parameters, or what happens if messages already exist in the inbox. It adds some context but misses important operational 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 well-structured with purpose statement, parameter explanations, return information, and an example. Every sentence adds value, though the example could be integrated more seamlessly. It's appropriately sized for a 2-parameter tool with clear sections.

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 2 parameters with 0% schema coverage but an output schema exists, the description provides adequate context. It explains what the tool does, what parameters mean, what it returns, and includes an example. The output schema means the description doesn't need to detail return values, making this reasonably complete for the tool's complexity.

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 0%, so the description must compensate. It provides clear semantic meaning for both parameters ('user_id: Your user ID', 'account_id: The ID of the seat'), explaining what they represent beyond just their names. However, it doesn't specify format constraints or provide examples of valid values beyond the single example.

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

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

The description clearly states the tool's purpose with specific verbs ('sync', 'retrieves', 'displays') and resources ('LinkedIn messages', 'platform inbox'). It distinguishes this tool from siblings like 'get_messages_for_leads' or 'get_all_conversations' by specifying it's for syncing LinkedIn messages to a centralized inbox rather than just fetching messages.

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 implies usage context ('for centralized message management') and mentions prerequisites ('specific seat'), but doesn't explicitly state when to use this tool versus alternatives like 'get_linkedin_user_info' or 'connect_linkedin_account'. It provides basic context but lacks explicit guidance on when-not-to-use or direct alternatives.

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