get_notifications
Retrieve your CoderLegion notifications to stay informed about community interactions.
Instructions
Get your CoderLegion notifications
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Retrieve your CoderLegion notifications to stay informed about community interactions.
Get your CoderLegion notifications
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v1.1.1Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden and delivers almost nothing. It doesn't state read-only nature, whether it requires auth, whether results are paginated, or how read state is handled.
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?
A single short sentence, front-loaded and waste-free. Nothing redundant or padded.
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 no-param tool, the description is functionally callable but omits nearly all useful context — no mention of auth requirement, pagination, sort order, or overlap with get_activity_feed. With no annotations and no output schema, the description is too thin.
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?
Zero parameters, so the baseline of 4 applies. There is nothing for the description to clarify beyond the schema's empty object.
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?
States a specific verb (get) and resource (notifications) scoped to the caller. Siblings are all posts/comments/profile/feed tools, so notifications is clearly distinguished, though the description doesn't elaborate on what notifications contain or how they're ordered.
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 guidance on when to use this versus get_activity_feed, which is a plausibly overlapping sibling. No exclusions, prerequisites, or context for when notifications should be fetched.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.