fetch_feedFetch and normalize any RSS / Atom / RDF feed by URL. CF-robust: fetches directly and falls back to a proxy if the source blocks the gateway. Use list_feeds first for curated sources.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Feed URL, e.g. "https://news.ycombinator.com/rss". | |
| limit | No | Max items (1-50, default 20). | |
| query | No | Keyword filter over item title/summary. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent nature. The description adds the CF-robust fallback proxy behavior, which is valuable beyond annotations. No contradictions.
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 sentences efficiently deliver purpose, behavioral trait, and usage guidance. No extraneous text.
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?
No output schema, and the description does not explain return format (e.g., normalized items). Given siblings and annotations, it's partially complete but missing output specification.
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 covers 100% of parameters with descriptions. The description adds no additional parameter context beyond mentioning 'by URL'; neither limit nor query are referenced. Baseline 3 is appropriate.
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 tool fetches and normalizes RSS/Atom/RDF feeds by URL, distinguishing it from siblings like list_feeds (curated sources) and read_feed (likely for subscribed feeds).
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?
Explicitly advises to use list_feeds first for curated sources, providing clear context. Lacks explicit guidance on when not to use, but the suggestion is helpful.
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.
Multiple tool families overlap heavily: ask_pipeworx/ask_pipeworx_beta/ask_pipeworx_grounded all route through the same 5,721 tools, polymarket_edges/polymarket_arbitrage/bet_research/polymarket_fill_risk all target prediction-market opportunities, and ai_visibility_check vs scan_competitor_ai_presence cover the same probe. An agent would struggle to pick the right one without reading every description carefully.
There are coherent subfamilies (ask_pipeworx_*, polymarket_*, remember/recall/forget, list/read/fetch_feed), but the overall set mixes verb-first names (list_feeds, validate_claim, fetch_feed) with noun-first names (entity_profile, bet_research, deep_research) and adjective-led names (recent_alerts, recent_changes). The inconsistency is noticeable but not chaotic.
34 tools is heavy for a server branded 'Law Feeds,' and many tools are off-domain (Polymarket betting, npm dependency scanning, AI visibility marketing, generic memory). The breadth could justify a larger catalog, but the overlapping research/Polymarket tools inflate the count beyond what the surface needs.
As a general data-gateway, the set is fairly complete: routing, grounded answers, deep research, entity resolution, comparison, subscriptions, memory, and feedback are all covered. Relative to the 'Law Feeds' identity, though, the surface is shallow — only list_feeds, read_feed, and fetch_feed serve that purpose, with no feed search, management, or update capabilities.