get_notifications
Return the generated meta description for the get_notifications tool.
Instructions
Open LinkedIn notifications and return visible items.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No |
Return the generated meta description for the get_notifications tool.
Open LinkedIn notifications and return visible items.
| Name | Required | Description | Default |
|---|---|---|---|
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It says the tool 'opens LinkedIn notifications,' implying navigation/side effects, and returns 'visible items,' implying a read. But it doesn't disclose whether it changes the browser state, what 'visible' means (scroll depth? loaded vs lazy-loaded?), or whether any accounts/setup are needed. The max_chars parameter hints at truncation, but nothing explains what happens to truncated content.
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 with no waste. However, it is under-specified rather than concisely complete—the brevity leaves critical gaps (parameters, prerequisites, behavior). It's efficient but sacrifices necessary context.
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 single-param tool with no annotations and no output schema, the description should at least explain the parameter, the navigation side effects, and what 'visible' items means. None of these are addressed. The tool appears to involve opening a page (side effect) and returning content, but the description doesn't cover the state change or how to interpret 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 description coverage is 0% and there's exactly one parameter (max_chars) with no description. The description doesn't explain max_chars at all—its purpose (limiting output length) is only inferable from its name and min/max bounds. With 0% coverage, the description must compensate but provides zero parameter information.
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 'Open LinkedIn notifications and return visible items' has a clear verb+resource (open + notifications) and does state what the tool does. However, it doesn't differentiate from siblings well—there's no mention of scope, recency, or how this differs from similar read tools like get_feed. It's functional but not specific enough to distinguish from related navigation/read 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 when-to-use guidance is provided. There is no mention of when this should be used versus alternative tools, whether navigation state matters (e.g., must be logged in first), or any prerequisites. The sibling tools suggest LinkedIn interaction may require prior login, but the description says nothing about this requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tiagoyamashita/openlinkedinmcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server