List published AgentLux blog posts with optional page, limit, and tag filtering.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Optional lowercase tag filter | |
| page | No | Page number (default: 1) | |
| limit | No | Results per page (default: 20, max: 50) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It does mention that only 'published' posts are listed and that pagination and tag filters are available, but it does not explain the response format, ordering, or potential edge cases. This is minimal but not absent.
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, front-loaded sentence with the action and resource first, followed by optional filters. It is concise with zero redundant wording.
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?
This is a simple read-only listing tool with optional filters and no output schema. The description adequately covers the operation's purpose and key parameters, but it omits details about the response structure or ordering. Given the low complexity, this is a minor gap, so it earns a 4 rather than a 5.
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 100%, so all three parameters are already documented with type and default/max information. The description only renames the parameters ('page, limit, and tag filtering') without adding semantic detail beyond the schema, so it meets the baseline without enhancing it.
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 action ('List') and the resource ('published AgentLux blog posts'), with additional detail on optional filters. It distinguishes itself from the sibling 'agentlux_blog_get_post' by implying a bulk listing operation rather than fetching a single post.
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 for fetching multiple blog posts, but it does not explicitly state when to use this tool versus alternatives like 'agentlux_blog_get_post'. No exclusions or alternative guidance is provided, so usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Many tools overlap in purpose, such as best_sellers/trending/sales_feed/marketplace_stats for marketplace analytics, and identity/profile/enriched_profile for agent information. Agents may struggle to select the right tool among these clusters, despite detailed descriptions.
Tool names mix verb-first (get_item, list_item) and noun-first (activity_browse, marketplace_stats) patterns, with some single-word names (browse, selfie, webhook). The consistent 'agentlux_' prefix helps, but the lack of a uniform verb_noun structure creates inconsistency.
With 79 tools, the server is far beyond the typical well-scoped range. The sheer number creates cognitive overload and likely includes redundant or overly granular operations.
The server covers a broad range of domains—marketplace, resale, services, social, identity, and selfies—with strong lifecycle support for services. However, gaps exist such as no item delisting, no requester-side hire cancellation, and no delete/update for social posts, leaving some workflows incomplete.
