Skip to main content
Glama

Riddle

by com.riddle

riddle_list

Read-onlyIdempotent

Returns a paginated list of Riddles. With the default scope "project" they come from a single project - use projectId to name it, or omit it for the personal project. With scope "account" they come from the entire account instead: the personal project and every team project the user has access to, in one list - the account-wide listing is this scope, not a tool of its own; projectId and notType do not apply there and are rejected rather than ignored. Every other filter works the same in both scopes. Answers with {items, page, pageSize, total, hasMore}, where "total" is how many Riddles match the filters in total and "hasMore" whether another page follows.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNoPage number, 1-indexed, 12 Riddles per page (default: 1). Zero or negative is rejected with a VALIDATION_ERROR rather than clamped.
tagsNoFilter by tag IDs (array of integers). Omit to ignore tags.
typeNoFilter by Riddle type (array of strings). Valid values: "Quiz", "Poll", "Form", "Personality", "Predictor", "Minigame", "Leaderboard", "Placeholder", "Story". Omit to include all types.
scopeNoWhat to list: "project" (default) for the Riddles of a single project, "account" for every Riddle of the account at once.
originNoFilter by how the Riddle was created: "api" (Riddle Builder API or Riddle AI, so riddle_delete/riddle_builder_update/palette_customize work on it) or "manual" (built by hand in the Creator, where those three are rejected). Omit for both. A filter value only - the "origin" returned per Riddle is {builder, aiGenerated, apiManageable}.
searchNoSearch term to filter Riddles by title
sortByNoSort field: "created", "published", or "modified"
statusNoFilter by status: "published", "modified", or "draft". Omit to include all statuses.
notTypeNoExclude specific Riddle types (array of strings, same valid values as type). Omit to exclude nothing. Scope "project" only - the account list has no exclusion filter.
projectIdNoFilter by project ID; omit or null for the authenticated user's personal project. Scope "project" only.
sortOrderNoSort direction: "ASC" or "DESC"

Schema Changelog

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

  1. Changed5 schema fields changed
    • changedInput schema / properties / notType / description
      Previous value: -"Exclude specific Riddle types (array of strings, same valid values as type). Omit to exclude nothing."New value: +"Exclude specific Riddle types (array of strings, same valid values as type). Omit to exclude nothing. Scope \"project\" only - the account list has no exclusion filter."
    • changedInput schema / properties / origin / description
      Previous value: -"Filter by how the Riddle was created: \"api\" (built via the Riddle Builder API or\ngenerated by the Riddle AI, so riddle_delete/riddle_builder_update/palette_customize\nwork on it) or \"manual\" (created by hand in the Creator, where those three are\nrejected). Omit to include both. Filter value only: the \"origin\" field returned per\nRiddle is an object {builder, aiGenerated, apiManageable}, not one of these strings."New value: +"Filter by how the Riddle was created: \"api\" (Riddle Builder API or Riddle AI, so\nriddle_delete/riddle_builder_update/palette_customize work on it) or \"manual\" (built by\nhand in the Creator, where those three are rejected). Omit for both. A filter value\nonly - the \"origin\" returned per Riddle is {builder, aiGenerated, apiManageable}."
    • changedInput schema / properties / page / description
      Previous value: -"Page number, 1-indexed, 12 Riddles per page (default: 1). Zero or negative is rejected with a VALIDATION_ERROR, not clamped to page 1 - the same contract as project_list/questionBank_list."New value: +"Page number, 1-indexed, 12 Riddles per page (default: 1). Zero or negative is rejected with a VALIDATION_ERROR rather than clamped."
    • changedInput schema / properties / projectId / description
      Previous value: -"Filter by project ID; omit or null for the authenticated user's personal project"New value: +"Filter by project ID; omit or null for the authenticated user's personal project. Scope \"project\" only."
    • addedInput schema / properties / scope
      Added value: +{
+  "default": null,
+  "description": "What to list: \"project\" (default) for the Riddles of a single project, \"account\" for every Riddle of the account at once.",
+  "enum": [
+    "project",
+    "account"
+  ],
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / page / description
      Previous value: -"Page number, 12 Riddles per page (default: 1)"New value: +"Page number, 1-indexed, 12 Riddles per page (default: 1). Zero or negative is rejected with a VALIDATION_ERROR, not clamped to page 1 - the same contract as project_list/questionBank_list."
  3. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already mark the operation as readOnly and idempotent, and the description adds valuable behavioral detail beyond that: the paginated response shape, "rejected rather than ignored" behavior for inapplicable filters, and the nuanced origin filter semantics. Nothing in the description contradicts the annotations.

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?

The description is dense but not bloated; every sentence contributes scope, filtering, or response information. It is front-loaded with the core purpose. A slight structural improvement would be breaking the long paragraph into scoped bullets, but it remains efficiently written.

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?

With 11 parameters, no output schema, and no required fields, the tool carries significant complexity. The description compensates by defining pagination fields, scope-specific behavior, rejection semantics, and filter applicability. The parameter schemas cover the remaining details, so an agent has enough context to call the tool correctly.

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, and the description adds meaning by clarifying scope-dependent rejection of projectId and notType, and by explaining that origin is a filter value while the per-Riddle origin is an object. This goes beyond the schema's individual parameter descriptions, though not dramatically.

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 and resource: "Returns a paginated list of Riddles." It then clearly differentiates the two scopes, including the explicit statement that the account-wide listing is this same tool, not a separate one, which distinguishes it from any potential sibling ambiguity.

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?

The description gives clear context for when to use project scope versus account scope and explains how projectId behaves when omitted. It also states that projectId and notType are rejected in account scope, which is useful exclusionary guidance. However, it does not explicitly name alternatives like riddle_get for single-resource retrieval, so the guidance stops short of a full when/when-not comparison.

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

All Riddle 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

A4.4/5.0
Disambiguation5/5

Each tool is scoped to a distinct resource/action area: media, palettes, projects, question banks, Riddles, templates, tags, stats, and support. Potentially close pairs like riddle_tag/riddle_tag_delete and question_bank_delete/question_bank_manage are cleanly separated by their descriptions, so an agent can reliably select the right one.

Naming Consistency4/5

The naming is mostly consistent snake_case with strong resource prefixes like riddle_, question_bank_, and template_, followed by clear verbs. Minor deviations such as question_bank_item, riddle_tag, and stats_fetch break the strict verb-noun pattern but remain predictable once the convention is understood.

Tool Count3/5

At 38 tools this is a heavy surface, though the breadth is justified by the many subdomains the server covers: media, palettes, projects, question banks, Riddles, templates, tags, and stats. Most tools earn their place, but the count sits above the range where an agent can quickly survey all options.

Completeness4/5

The set covers the full lifecycle for Riddles, question banks, templates, and tags, including publish/unpublish, move, stats, and media upload/delete. Minor gaps like no media library listing and read-only project settings are workable because media IDs come from upload responses and project permissions are exposed.

Resources