signal-bureau

get_desk_feed

Read-onlyIdempotent

A newsletter DESK's machine feed at one predictable, slug-addressable location: up to 14 days of the desk's observed items (title, url, source), newest-first, from the same panel the human edition reads. Unlike watch topics, the desk roster is PUBLIC PRODUCT — the desks are: cognitive-investor, tax-nexus, crc-kras, crc-digest, space-economy, paradise-valley, lyt-intel, aztc-aasd, newspace-asu, lq-listening, jedi-knowledge, ud-articles, ecomm-news — so an unknown-desk reply lists them freely. Delivery is keyed (your self-issued key, x-api-key): identified delivery is the standard shape for standing feeds. Desks are priced as labeled topic bundles at the published Watch rate — see DESK_BUNDLES on /api/tariff and get_quote for your exact basket. Each feed's payload declares its own coverage state. Limits, stated: each day serves at most the projection's servedPerDay items and states held/served/tailStored/tailOmitted (held = served + tailStored + tailOmitted). The ranked tail below the cut is read with tail:true and walked with the returned cursor, pageSize 1-100 (default 50) — a page limit is a cursor, never an edge. Refusals name their code: bad_cursor, cursor_stale (the projection rebuilt; restart the walk), page_size_limit, tail_unavailable (cannot-measure: this build stores no tail, which is not a statement that the desk held nothing more).

Input Schema

TableJSON Schema

Name	Required	Description
`days`	No	How many recent days to return (1-14, default 14)
`desk`	Yes	The desk slug (e.g. 'space-economy')
`tail`	No	Optional. true reads the ranked TAIL instead of the served list: the items this desk held below the served cut, in curation-score order, each keeping its corroboration tier. Ranked, not curated. Omit it and the payload is unchanged.
`cursor`	No	Optional. The `tail.cursor` a previous tail page returned (implies tail). Opaque and interchangeable with /api/desk-feed?cursor=. Pinned to desk, window and projection build: a cursor from an older build is refused (cursor_stale) — start again with tail:true.
`pageSize`	No	Optional, tail only. Items per tail page, an integer 1-100 (default 50). Out of range is refused (page_size_limit), never clamped.

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 15, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "Optional. The `tail.cursor` a previous tail page returned (implies tail). Opaque and interchangeable with /api/desk-feed?cursor=. Pinned to desk, window and projection build: a cursor from an older build is refused (cursor_stale) — start again with tail:true.",
+  "type": "string"
+}

addedInput schema / properties / pageSize

Added value: +{
+  "description": "Optional, tail only. Items per tail page, an integer 1-100 (default 50). Out of range is refused (page_size_limit), never clamped.",
+  "type": "number"
+}

addedInput schema / properties / tail

Added value: +{
+  "description": "Optional. true reads the ranked TAIL instead of the served list: the items this desk held below the served cut, in curation-score order, each keeping its corroboration tier. Ranked, not curated. Omit it and the payload is unchanged.",
+  "type": "boolean"
+}

First observedAug 17, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already establish read-only/idempotent/non-destructive, and the description layers substantial extra behavior on top: identified delivery via a self-issued x-api-key, the servedPerDay limit with held/served/tailStored/tailOmitted accounting, cursor semantics (interchangeable with /api/desk-feed, pinned to build), and named refusal codes (bad_cursor, cursor_stale, page_size_limit, tail_unavailable). This is well beyond what the annotations carry.

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?

Purpose is front-loaded before differentiation, auth, pricing, limits, and refusals, so the important routing information comes first. It is dense and occasionally run-on (the pricing and coverage-state clauses are packed), which costs some readability, but few sentences are pure filler.

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?

With no output schema, the description carries the burden of return-value disclosure and does so partially: it names the item fields (title, url, source), states the payload declares its coverage state, and explains the tail fields and cursor. A five-param, cursor-paged feed could still use a clearer picture of the top-level response shape, but the essential pieces are present.

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?

Schema description coverage is 100%, so the schema already documents days, desk, tail, cursor, and pageSize. The description reinforces cursor stability, the pageSize range, and the tail/window relationship but adds little syntax the schema does not already supply. Baseline 3 applies.

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?

States a specific verb and resource: a desk's machine feed at a slug-addressable location, up to 14 days of observed items (title, url, source), newest-first. It explicitly distinguishes itself from 'watch topics' and names the sibling concept, and enumerates the valid desks, so an agent can identify exactly what this returns without opening the schema.

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 contrasts itself with the watch-topic path and routes pricing questions to get_quote and /api/tariff, and it explains when to use tail:true vs the default served list. It stops short of naming a sibling like get_watch_feed directly, but the contrast with 'watch topics' is clear enough for correct selection.

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

All signal-bureau 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.

Resources

Need Help?