list_newsletter_subscribersRetrieve newsletter subscribers from Misar.Blog with pagination controls, so you can review and manage your subscriber list. Requires API key authentication.
Get your newsletter subscriber list. Requires API key authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| offset | No |
Changes observed during successful MCP inspections.
v5.1.3Input schema / properties / limit / descriptionRemoved value: -"Subscribers per page, 1-100. Defaults to 20."Input schema / properties / offset / descriptionRemoved value: -"Subscribers to skip before this page. Defaults to 0."v5.1.0Input schema / properties / limit / descriptionAdded value: +"Subscribers per page, 1-100. Defaults to 20."Input schema / properties / offset / descriptionAdded value: +"Subscribers to skip before this page. Defaults to 0."v2.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds one useful fact beyond them: API key authentication is required. It omits pagination behavior or result ordering, which would be valuable for a list tool.
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?
Two compact sentences, front-loaded with the purpose and followed by the auth requirement. No filler, though the second sentence is arguably the only value beyond the name.
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 simple read-only list tool, minimal description is defensible, and the auth note is helpful. However, with no output schema and zero param documentation, pagination semantics (limit default 20, max 100, offset) are entirely absent, leaving an agent to guess at return size behavior.
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 coverage is 0% for two parameters (limit, offset), and the description says nothing about pagination, defaults, or ranges. With undocumented params, the description is expected to compensate and does not.
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 and resource ('Get your newsletter subscriber list'), which clearly separates it from siblings like list_newsletter_issues. It stops short of explicitly naming or contrasting with those siblings, so it is clear but not maximally distinguishing.
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 gives no when-to-use context, no prerequisites beyond auth, and no alternatives. An agent gets no guidance on choosing this over list_newsletter_issues or other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.