mcp-server

Create Listing Feed

alterlab_feed_create

Run a listing on a cron and get one signed webhook per run with only the new, changed (field-level previous/current plus provenance) and removed entities. The monthly cap is hard: the feed stops (status capped) rather than exceed it, and only valid results are billed. Returns the feed, its expected monthly cost and the webhook secret once. Set preset to new-merchant-radar (slug maps-places) or business-contact-refresh (slug website-contacts) for AlterLab Official defaults. Schedules more frequent than the server minimum interval (60 minutes by default) are rejected with a 422.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "slug": "<slug>",
      "monthly_cap_microcents": "<monthly_cap_microcents>"
    },
    "name": "alterlab_feed_create"
  }
}

Input Schema

Name	Required	Description
`slug`	Yes	Listing slug
`input`	No	Listing input; validated against the listing input_schema
`preset`	No	AlterLab Official feed preset name
`timezone`	No	IANA timezone. Default: UTC
`max_results`	No	Results per run. Default: 100
`webhook_url`	No	https URL that receives the delta
`delivery_mode`	No	delta sends only changes, full sends every result. Default: delta
`cron_expression`	No	Five-field cron; required unless a preset supplies it. Must not fire more often than every 60 minutes (server minimum)
`monthly_cap_microcents`	Yes	Hard monthly spend cap in microcents

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Beyond the annotations (which only say it is a non-idempotent, non-destructive, open-world write), the description discloses the hard monthly cap that halts the feed with status 'capped', the billing rule that only valid results are charged, and the one-time return of the webhook secret. These are exactly the operational facts an agent cannot otherwise infer.

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?

Three tight sentences with the core behavior front-loaded and no filler; the preset guidance and the 422 rule are both genuinely load-bearing. The final 60-minute clause only partially duplicates the cron_expression schema text, so there is minor redundancy.

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

Completeness4/5

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

For a 9-parameter, nested-input creation tool with no output schema, the description covers scheduling, billing, cap behavior, presets, and the one-time secret return. The only soft spot is the nested 'input' object, which is deferred entirely to the listing's own input_schema without saying how to obtain it.

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

Parameters4/5

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

Schema coverage is already 100%, so the baseline is 3, but the description adds real meaning by mapping each preset name to its listing slug and restating the cron minimum interval that drives a 422. It leaves delivery_mode and max_results semantics to the schema, which is acceptable given full coverage.

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

Purpose4/5

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

The description opens with a concrete verb+resource ('Run a listing on a cron and get one signed webhook per run'), which unambiguously identifies a feed-creation tool rather than a listing or delta-read tool. It does not explicitly name the sibling alternatives (alterlab_feed_update, alterlab_feed_list, alterlab_feed_deltas), so the differentiation is inferred from the creation framing rather than stated.

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 gives actionable selection guidance for the preset parameter ('Set preset to new-merchant-radar ... or business-contact-refresh ... for AlterLab Official defaults') and states the schedule constraint that causes rejection (422 above the 60-minute minimum). It stops short of saying when to prefer this create tool over feed_update or feed_deltas, so no explicit exclusions are offered.

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

All mcp-server tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.