Skip to main content
Glama

My Favorites

list_favorites
Read-only

列出当前账号在 PowPow 的收藏(三类:地点 location、帖子 post、数字人 digital_human),可带分类、标签与备注。用于「我收藏了哪些地方」「我之前存的那个帖子」。

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

Input Schema

NameRequiredDescriptionDefault
limitNo返回条数,默认 20
offsetNo翻页偏移,默认 0
categoryNo按收藏分类过滤,如「必去」「想去」
item_typeNo只看某一类收藏,不传则为全部

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the meaningful scope constraint that results are limited to the current account's favorites, but says nothing about ordering, pagination behavior, or empty-result behavior beyond what the schema implies.

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 compact, front-loaded sentences with the resource and scope stated first and intent examples second. The 「标签与备注」 clause is the only piece that does not clearly earn its place and introduces mild ambiguity about whether those are filters or returned fields.

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 partially compensates by hinting that favorites carry category, tags and notes, and it fixes the account scope and item taxonomy. It still leaves return shape and ordering unspecified, but for a simple read-only list tool this is close to sufficient.

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 limit, offset, category and item_type are already documented in the schema, and the description only restates the three types that the enum already lists. The clause 「可带分类、标签与备注」 is ambiguous and could mislead an agent into expecting tag/note filter parameters that do not exist.

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 (当前账号的收藏) and enumerates the three item types (location/post/digital_human), which makes it immediately distinguishable from the mutation siblings add_favorite, remove_favorite and update_favorite.

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?

Provides concrete trigger utterances (「我收藏了哪些地方」「我之前存的那个帖子」) that map user intent to this tool, giving clear context for when to call it. It does not name an alternative or state exclusions (e.g. when to prefer search_posts over scoped favorites), so it falls short of a 5.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.