Skip to main content
Glama

Pipeworx Trending

pipeworx_trending
Read-onlyIdempotent

What other AI agents are calling on Pipeworx right now. Returns the top tools, top packs, and total call volume over a recent window (24h, 7d, or 30d). Useful for: (1) discovering what data sources are hot for current events, (2) confirming a popular tool is the canonical choice before asking your own question, (3) seeing whether your use case aligns with what most agents need. Self-aggregating signal — derived from CF analytics-engine, no PII, just (pack, tool, count). Cached 5min-1h depending on window.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
windowNo24h (default) | 7d | 30d. Shorter windows surface what's hot right now; longer windows show steady-state demand.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring safe read-only behavior, the description adds valuable context: caching (5min-1h), no PII, and derivation from CF analytics-engine. It explains the self-aggregating nature and that it only contains (pack, tool, count) information, which goes beyond the annotations. No behavioral traits are omitted that matter for a read-only trending query.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then lists use cases and technical notes efficiently. Every sentence earns its place without redundancy. It is slightly longer than necessary but well-structured, avoiding fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one optional parameter, no output schema), the description fully covers what it returns (top tools, packs, count), the window semantics, caching caveats, and privacy guarantees. The use-case list adds operational context. It is complete for an agent to invoke correctly without needing additional information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter 'window' is fully described in the schema (100% coverage), including the same explanation about shorter vs longer windows. The tool description does not add new meaning beyond the schema, so the baseline of 3 is appropriate. It repeats the default value (24h) but adds no extra syntax or format details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('returns') and a precise resource: 'top tools, top packs, and total call volume over a recent window.' It clearly distinguishes this from sibling tools like discover_tools by focusing on what other AI agents are calling, which is unique. The purpose is immediately clear and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides three explicit use cases: discovering hot data sources, confirming canonical tool choice, and checking alignment with agent needs. It also gives guidance on window selection ('Shorter windows surface what's hot right now; longer windows show steady-state demand'). However, it does not mention alternatives or when not to use this tool, lacking exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Many tools overlap in purpose: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and validate_claim all provide data retrieval with subtle differences. The Polymarket suite (arbitrage, edges, edge_tracker, fill_risk, kalshi_spread) and AI visibility tools (ai_visibility_check, scan_competitor_ai_presence) also have fuzzy boundaries. While some tools are clearly distinct, the overall set has significant ambiguity that could lead to misselection.

Naming Consistency2/5

Tool names mix conventions: some are verb_noun (search_networks, compare_entities, remember, forget), others are noun_compound (entity_profile, polymarket_edges, ask_pipeworx), and a few are verb-only (recall, forget). The pattern is inconsistent, with no clear naming strategy across the tool surface.

Tool Count2/5

With 34 tools, the server is heavily overloaded. While it serves as a general data platform, many tools are meta-level (discover_tools, suggest_questions) or peripheral (subscriptions, memory). The count feels excessive for the core purpose, and many tools could be consolidated or removed.

Completeness1/5

Despite the server name 'Peeringdb', only three tools (search_networks, search_facilities, search_exchanges) directly serve that domain. The vast majority of tools cover unrelated areas (Pipeworx data, Polymarket betting, AI visibility, memory, subscriptions). For the declared purpose of PeeringDB, the surface is severely incomplete—missing common operations like retrieving network details, viewing IX members, or managing peering policies.