GiftQuest

List my quests

list_my_quests

Read-only

Quests of this account, newest first, a page at a time: its own (role "owner") and ones shared with it for co-editing (role "editor"), with whether each gift has been opened and the recipient's thank-you (reply), if any. When next is not null there are more: call again with cursor = next.

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_my_quests"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Quests per page (default 50).
`cursor`	No	`next` from the previous call; omit for the first page.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 6, 2026

addedInput schema / properties / cursor

Added value: +{
+  "description": "`next` from the previous call; omit for the first page.",
+  "type": "string"
+}

addedInput schema / properties / limit

Added value: +{
+  "description": "Quests per page (default 50).",
+  "maximum": 100,
+  "minimum": 1,
+  "type": "integer"
+}

First observedNov 5, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover safety (readOnlyHint=true, openWorldHint=false), and the description adds real behavior: sort order (newest first), page-at-a-time semantics, role-based inclusion, and what each item carries (opened state, recipient reply). Missing only details like default page size, which the schema already supplies.

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?

Two sentences, front-loaded with the resource and scope, then the pagination rule. Dense with parenthetical asides but no filler; every clause conveys information an agent needs.

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 describing returned content and does so (opened status, thank-you reply). Pagination and ordering are covered; only page-size behavior is left entirely to the schema.

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 coverage is 100%, so both parameters are already documented. The description restates the cursor pattern from the schema and says nothing about `limit`, so it adds no meaning beyond the structured fields; baseline 3 applies.

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 states a specific resource and scope: quests of this account, split by role (owner vs editor), ordered newest first, paginated, including opened status and reply. That is enough to separate it from get_quest (single resource) or create_quest, though no sibling is named explicitly.

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?

Pagination guidance is explicit ('When `next` is not null ... call again with cursor = next'), but there is no statement of when to prefer this tool over get_quest or when it should not be used. Usage is implied by the listing scope rather than stated.

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

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