search_publicSearch public people by username, and public spaces or networks by name or username (no login). Networks are spaces with kind "network". Use a space or network id with set_guest_context.
| Name | Required | Description | Default |
|---|---|---|---|
| q | Yes | Username, space name, or space/network username | |
| limit | No | Max results (1–20). Digits as text are accepted. |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, and closed-world behavior. The description adds useful context beyond annotations: no login is required, networks are identified as spaces with kind "network", and results can feed into set_guest_context. It does not describe result ordering, pagination, or rate limits, but with strong annotation coverage this is a solid addition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted wording. The primary capability is front-loaded, followed by the network definition and the downstream set_guest_context hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter public search tool with full annotation coverage, the description gives enough context to invoke it correctly. The main minor gap is that it does not summarize the result shape or combined people-and-spaces output, but no output schema exists and the essential usage context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so both q and limit are already documented in the input schema. The description reinforces that q accepts usernames, space names, or space/network usernames, but adds little beyond the schema's own parameter descriptions. Baseline 3 is appropriate when the schema carries the parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resources: searching public people by username and public spaces or networks by name or username. It also defines that networks are spaces with kind "network". However, it does not distinguish this combined search from the sibling tools search_public_people and search_public_spaces.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that the search works without login and that a returned space or network id can be used with set_guest_context. This implies a public/anonymous usage context, but it does not explicitly state when to use this combined search instead of the dedicated people or spaces search siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.