Return parsed Atom feed entries for a user's WhatDoTheyKnow activity.
Unlike the raw wdtk://users/{slug}/feed resource, this returns structured
entries with the Atom content converted to readable text in content and
mirrored to summary for clients that only display summary fields.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| user_slug | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, openWorldHint, and idempotentHint, yet the description adds valuable behavioral detail: it converts Atom content to readable text in `content` and mirrors it to `summary`. This explains output behavior beyond what annotations or an output schema might imply, and there is no contradiction with the annotations.
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 two sentences, with the core purpose front-loaded and no unnecessary words. The contrast with the raw resource is concise and adds meaningful value without padding.
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 the simple two-parameter schema and the presence of an output schema, the description covers the essential transformation (Atom to readable text) and the user-specific scope. It lacks some details like pagination or error handling, but the output schema and annotations mitigate those needs. It could be slightly stronger by explicitly distinguishing from get_request_feed_items.
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?
The schema has no descriptions for `user_slug` or `limit`, and the description barely addresses them. It indirectly references `user_slug` via 'a user's WhatDoTheyKnow activity' but never explains the `limit` parameter or its default behavior. With 0% schema description coverage, the description fails to compensate, leaving parameter semantics largely unspecified.
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 opens with 'Return parsed Atom feed entries for a user's WhatDoTheyKnow activity', clearly identifying the action (return) and resource (user feed entries). It also explicitly contrasts with the raw wdtk://users/{slug}/feed resource, distinguishing it from a simplified version. This uniquely differentiates it from sibling tools like get_request_feed_items.
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 provides clear context by contrasting with the raw resource and explaining that this returns structured entries with Atom content converted to readable text. However, it does not explicitly name alternatives like get_request_feed_items or state when to prefer this over them, so it stops short of full when/when-not guidance.
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.
Most tools are clearly distinct, but get_user_feed_items and get_user_requests both surface user activity, and get_request_feed_items vs get_request_detail could be confused. Descriptions help differentiate them, but the overlap creates minor ambiguity.
All tool names follow a consistent snake_case verb_noun pattern (build_, create_, get_, list_, search_, update_). No mixing of conventions or vague verbs.
12 tools are well-scoped for the domain, covering read, search, write, and feed operations without bloat. The prompts-related tools are ancillary but not excessive.
Core workflows are covered: authority lookup, request search/detail, user requests, creation, and state updates. Missing user detail or direct authority request list can be worked around with existing search and feed tools.