SuperPost

List ideas

list_ideas

Read-onlyIdempotent

Reads the workspace idea catalog with optional generic text search, source provenance search, topic, label, and cursor-based pagination. The sourceQuery filter matches source author, handle, source title or filename, provider, remote item ID, or URL; English/Russian transliterations match, and | separates alternate spellings. Provenance search does not match names mentioned only in idea text or source excerpts. Returned source attributions are bounded. This is read-only.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_ideas"
  }
}

Input Schema

Name	Required	Description	Default
`sort`	No		updatedAt
`label`	No
`limit`	No
`topic`	No
`cursor`	No
`search`	No
`direction`	No		desc
`sourceQuery`	No	Search saved provenance metadata, such as an author or source filename. English/Russian transliterations are supported; use \| to include alternate spellings.

Output Schema

Name	Required	Description	Default
`items`	Yes
`nextCursor`	No
`totalCount`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 5, 2026

TDQS

A4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description adds real value with the transliteration/`|` matching rules, the explicit limitation that provenance search will not surface names appearing only in idea body text, and the note that returned source attributions are bounded. The closing "This is read-only" is redundant with the annotations, and nothing is said about ordering defaults or result volume limits.

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?

Four dense sentences, front-loaded with purpose and filter inventory, with no filler. Minor waste comes from restating read-only and repeating the sourceQuery transliteration rules that the schema property description already carries.

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?

This tool is complex (8 parameters, 0 required, 13% schema documentation) and the description covers the risky, non-obvious parts: the two distinct search modes, their matching semantics, and the bounded attribution output. With an output schema present, return-value shape need not be described, so what remains missing (per-filter match semantics) is modest.

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 only 13%, so the description must compensate, and it explains sourceQuery thoroughly and names search/topic/label/cursor by role. It still adds no meaning for `search` (which fields are matched), `topic`/`label` (exact vs partial, case sensitivity), or how `sort` and `direction` interact with the cursor, leaving half the parameter set described by name only.

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 specific verb+resource ("Reads the workspace idea catalog") and enumerates the supported filter dimensions, which is enough to distinguish it from list_posts, list_threads, and search_sources. It also scopes the operation as read-only on a single workspace.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clarifies the boundary between the two text filters (sourceQuery hits provenance metadata, not names merely mentioned in idea text or excerpts), which is genuine when-to-use guidance for choosing a filter. However, it never names an alternative tool or states when to use this versus search_sources or list_posts, so the sibling routing is left implicit.

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

All SuperPost 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?