Skip to main content
Glama

Subscribe to Alerts

subscribe
Idempotent

Create a proactive monitoring subscription to a live-data event stream. Returns the new subscription id. Requires a Pipeworx OAuth account (anonymous + BYO cannot persist subscriptions). Supported types: "sec_8k" (8-K filings matching ticker + item codes — e.g. items:["5.02"] = officer change), "polymarket_edge" (Polymarket↔Kalshi cross-venue mispricings — params:{topic:"fed"}), "fred_series" (new FRED observations — params:{series_id:"UNRATE"}). Delivery channels: feed (always on — pull via recent_alerts or GET registry.pipeworx.io/alerts.json), and optionally email (set delivery:{email:"you@x.com"}) or sms (delivery:{sms:"+15551234567"} — phone must be verified at /account first; 10/day cap).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeYesSubscription type.
paramsYesType-specific filter. sec_8k: {ticker:"AAPL", items?:["5.02","1.01"]}. polymarket_edge: {topic:"fed", min_spread_bps?:500}. fred_series: {series_id:"UNRATE"}. patent_grant: {applicant:"Apple Inc."}. clinical_trial: {sponsor?:"Pfizer", condition?:"lung cancer", phase?:"PHASE3"} (sponsor or condition required).
deliveryNoOptional delivery channels in addition to the always-on persistent feed. {email:"you@x.com"} sends a templated alert per fired event. {sms:"+15551234567"} sends an SMS per event — must match the verified phone on the caller's account (verify at https://pipeworx.io/account first; 10/day cap). {webhook:"https://..."} POSTs each event JSON to your endpoint, HMAC-signed — the response includes delivery.webhook_secret (whsec_…) ONCE; verify X-Pipeworx-Signature = sha256 HMAC of "<X-Pipeworx-Timestamp>.<raw body>". Auto-disabled after 10 consecutive failing runs.

TDQS

A4.8/5.0
Behavior5/5

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

The description discloses behavioral traits beyond annotations: it creates a persistent subscription, returns an id, and details delivery channel behaviors (feed always on, webhook secret returned once, auto-disable after failures). No contradictions with annotations (readOnlyHint=false, idempotentHint=true).

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

Conciseness5/5

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

Every sentence adds value, front-loading the main purpose and return. The description is detailed but not verbose, with clear separation of type-specific params and delivery options.

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?

The description covers all needed context: purpose, return value, prerequisites, type-specific parameters, delivery channels with constraints, and behavioral notes (webhook secret, auto-disable). Despite no output schema, the return value is mentioned.

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

Parameters5/5

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

Schema coverage is 100%, and the description adds significant value by explaining parameter formats with examples (e.g., sec_8k items, polymarket_edge topic) and constraints (phone must match verified number). This goes well beyond the schema.

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 clearly states 'Create a proactive monitoring subscription to a live-data event stream' and specifies the return of a new subscription id. It distinguishes the tool from siblings like 'unsubscribe' and 'list_subscriptions' by its unique purpose.

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 explicit prerequisites (Pipeworx OAuth account, anonymous/BYO cannot persist) and details for each subscription type. It also mentions limitations (10 SMS/day, phone verification). However, it does not explicitly compare to alternatives or state when not to use.

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

B3.4/5.0
Disambiguation2/5

Multiple tools have overlapping purposes (e.g., ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded; deep_research; bet_research and multiple polymarket tools). This makes it difficult for an agent to distinguish which tool to use.

Naming Consistency4/5

Tool names consistently use snake_case and follow a verb_noun or noun_verb pattern. However, some names are very long and descriptive (e.g., polymarket_kalshi_spread, scan_competitor_ai_presence), which is acceptable but slightly inconsistent in length.

Tool Count3/5

With 38 tools, the server is on the high side of reasonable. Many are meta-tools or query routers, which inflates the count. The scope is very broad, covering diverse domains, making the number somewhat justifiable but still feeling heavy.

Completeness3/5

For the Dailymed domain, tools cover label search, retrieval, history, and comparison. However, many other domains (e.g., finance, prediction markets) rely on a handful of routing tools (ask_pipeworx) rather than dedicated tools, leaving the coverage uneven and not fully self-contained.