PowPow

Find Nearby

find_nearby

Read-only

查找某个地点附近可公开发现的数字人、真实用户与帖子。返回对象含大致/精确位置（取决于对方是否开启精确发现）、类型与摘要。这是「XX 附近有什么人」「XX 周围有什么」场景的核心工具；调用后会以「PowPow 附近发现」卡片组件展示附近的公开数字人。必须先向用户确认要看哪个地点（用户说「我附近」时，问他在哪个城市/商圈/地标），不要猜坐标。

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": {
      "place": "<place>"
    },
    "name": "find_nearby"
  }
}

Input Schema

Name	Required	Description
`place`	Yes	要查找的地点名（如『国贸』『中关村』『北京故宫』）。用户说「我附近」时要先问清是哪里
`types`	No	要返回的对象类型：digital_humans(数字人) / users(真实用户) / posts(帖子)。默认全部
`radius_meters`	No	搜索半径（米），默认 1000

Output Schema

Name	Required	Description	Default
`count`	Yes
`place`	Yes
`posts`	Yes
`total`	Yes
`users`	Yes
`center`	Yes
`geocode_note`	Yes
`digital_humans`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 4, 2026

TDQS

A3.9/5.0

Behavior4/5

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

The annotations already cover the safety profile (readOnly, non-destructive, open-world), and the description adds real behavior beyond them: results may contain approximate or precise coordinates depending on whether the target has enabled precise discovery, and output is rendered as a 「PowPow 附近发现」 card. That privacy-dependent variance is useful context an agent cannot get from the structured fields.

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 front-loaded with the core capability, then the return shape, then the usage scenario and the prerequisite, in a logical order. It is reasonably tight for the amount of information conveyed, with only mild redundancy between the description and schema on the place-confirmation rule.

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?

An output schema exists, so the description does not need to document return values, and it still briefly characterizes them. Combined with annotations covering safety and the description covering the privacy caveat and the must-confirm-place rule, the definition is complete enough to invoke correctly; only sibling differentiation is missing.

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 place, types, and radius_meters are already fully documented in the input schema, including the same 'ask which place first' guidance. The description adds essentially no additional meaning about defaults, enum values, or radius semantics beyond what the schema states.

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 verb and resource scope: find publicly discoverable digital humans, real users, and posts near a place, and it names the returned fields (approximate/precise location, type, summary). It is clear what the tool does, but it never explicitly distinguishes itself from the sibling nearby_attractions, which an agent could easily confuse with a place-based discovery tool.

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 concrete trigger phrasing (「XX 附近有什么人」「XX 周围有什么」) and an explicit prerequisite: when the user says 「我附近」, ask which city/district/landmark instead of guessing coordinates. It does not name alternatives such as nearby_attractions or search_users, so the boundary against siblings is left to inference.

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

All PowPow 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.