Skip to main content
Glama

Arcgis Abbotsford

by io.github.pipeworx-io

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.

Schema Changelog

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

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations indicate non-read-only, idempotent, non-destructive, but the description goes far beyond by detailing OAuth requirements, the returned subscription id, delivery channel behaviors (email, SMS with 10/day cap, webhook with HMAC signing and auto-disable after 10 failures). This fully discloses behavioral consequences without contradicting annotations.

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?

The description is dense but every sentence carries essential operational detail. It is front-loaded with the purpose, then prerequisites, then type-specific parameters, then delivery options. No filler or repetition; the length is justified by the tool's complexity.

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 has 3 parameters (one nested), no output schema, and meaningful side effects, the description covers prerequisites, all parameter semantics, return value, delivery behavior, failure limits, and security details. It is complete enough for an agent to select and invoke correctly without additional lookup.

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%, so baseline is 3, but the description adds substantial semantic meaning: it explains each subscription type with concrete examples (e.g., items:["5.02"] = officer change), details the params object structure for each type, and elaborates on delivery channel parameters (verification, caps, webhook signing). This goes well beyond the schema's terse descriptions.

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 opens with a clear verb-resource statement: 'Create a proactive monitoring subscription to a live-data event stream.' It distinguishes this from sibling tools like list_subscriptions, unsubscribe, and recent_alerts by focusing on creation and returning a subscription id.

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?

It explicitly states the prerequisite of a Pipeworx OAuth account and excludes anonymous/BYO users, which is a when-not-to-use condition. It also mentions the always-on feed and how to pull alerts via recent_alerts, providing an alternative consumption method. It doesn't explicitly say 'use this instead of X', but the context is clear.

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

All Arcgis Abbotsford toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.6/5.0
Disambiguation2/5

Several tools have heavily overlapping purposes: ask_pipeworx, ask_pipeworx_beta, ask_pipeworx_grounded, deep_research, and discover_tools all provide data lookup/research. The PolyMarket family (bet_research, polymarket_arbitrage, polymarket_edges, polymarket_edge_tracker, polymarket_fill_risk, polymarket_kalshi_spread) also creates boundary confusion despite varied signals.

Naming Consistency3/5

Most tools use snake_case, but the naming pattern is mixed: some are imperative verb phrases (query_layer, validate_claim), while others are noun phrases (entity_profile, recent_alerts, layer_info). Descriptions are readable overall, but there is no consistent verb_noun convention across the set.

Tool Count2/5

34 tools is high and the vast majority are unrelated to the server's stated ArcGIS Abbotsford purpose. The set appears to be a generic Pipeworx data/prediction-market toolkit with only a few GIS-specific tools, making the count excessive for the declared scope.

Completeness2/5

For the ArcGIS Abbotsford domain, the surface is severely incomplete: only search_datasets, query_layer, and layer_info cover GIS functionality, lacking update/delete/create operations or broader dataset management. For the actual Pipeworx domain, coverage is decent, but that does not match the server name.

Resources