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. A desk of your own, built around your question: ask us (send_feedback, or lead@evfm.co). 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).

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": {
      "desk": "<desk>"
    },
    "name": "get_desk_feed"
  }
}

Input 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

Behavior4/5

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

Annotations already cover the read-only, idempotent, non-destructive, closed-world profile, yet the description adds substantial behavioral detail beyond them: x-api-key self-issued key delivery, per-day servedPerDay cap with the held = served + tailStored + tailOmitted invariant, cursor pinning to a projection build, and named refusal codes (bad_cursor, cursor_stale, page_size_limit, tail_unavailable) including the 'cannot-measure' caveat. Minor deductions for the dense, slightly buried phrasing of these guarantees.

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

Conciseness3/5

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

The purpose is correctly front-loaded in sentence one, but the paragraph then spirals into dense jargon (projection, tail, corrobation tier, cannot-measure) without paragraph breaks or bullets, and it repeats schema facts like pageSize 1-100 default 50. Every clause carries information, but the structure makes it hard to scan and the 13-slug roster bloats the middle.

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?

There is no output schema, and the description compensates by describing the payload shape (title, url, source, newest-first, self-declared coverage state, held/served/tailStored/tailOmitted counters, tail.cursor) and the failure taxonomy. For a five-parameter read tool with pagination, that is enough for an agent to call and interpret it correctly without further documentation.

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 description coverage is 100%, so the baseline is 3; the description earns more by adding semantics the schema does not — that omitting tail leaves the payload unchanged, that cursor implies tail and is interchangeable with the /api/desk-feed?cursor= form, that a page limit never truncates the tail, and that out-of-range pageSize is refused rather than clamped. Some overlap remains (1-14, 1-100 defaults restated).

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 opening names a specific verb+resource+scope: a desk's machine feed, up to 14 days of observed items (title, url, source), newest-first, at a slug-addressable location. It explicitly distinguishes itself from the watch-topic family (get_watch_feed, list_standard_watches) and even enumerates valid desk slugs, so an agent can recognize the tool 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 the tool against watch topics (the desk roster is public, so unknown-slug replies list desks freely) and explains the served-vs-tail mode split and the cursor walk. What it does not state is the positive selection rule against get_watch_feed/list_standard_watches — i.e. 'choose this when you want a standing public feed rather than a saved watch' — leaving that inference to the reader.

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?