VTC Spaces

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description adds genuinely new context: answers are grounded strictly in public-to-AI fields, it uses the same route as the guest support chat, and the Space bears the cost. It does not mention error modes or rate limits, but the added scope/cost context is valuable.

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?

Three tight sentences, front-loaded with the action and example, followed by the scope constraint and the cost note. No filler, though the cost sentence is slightly tangential.

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?

With no output schema, the description should ideally indicate what an answer looks like (e.g., text answer with citations). It covers grounding and cost but leaves the return shape unstated, a moderate gap for a query tool.

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 67%; 'space' and 'conversation_id' are documented in the schema itself, while 'question' lacks a schema description. The description adds that the question is plain text with an example, which partially compensates, but adds little beyond that. A 3 baseline fits.

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?

States a specific verb (ask a question) and resource (a Space's public AI Support), plus scoping detail that answers come only from documents the Space marked 'Public to AI Support'. This is clearly distinguishable from siblings like search_public or list_space_public_documents, which retrieve rather than answer.

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 example question and the 'answers only from... documents marked Public to AI Support' constraint tell an agent what this tool will and won't answer. However, it doesn't explicitly name when to prefer a sibling (e.g., search_public for direct document retrieval) over this.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds the important auth trait that no Space JWT is required and hints at returned content, but does not describe response shape, error behavior, or limitations.

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 short sentences with no filler. The core output is front-loaded, followed by the auth condition.

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 read-only tool, annotations and schema cover most structured needs. Because there is no output schema, the description should explain the return value more concretely than 'AI manifest plus guest/public read hints', but it is still minimally sufficient to invoke the tool.

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 description coverage is 100%, so both group_id and module_code are already documented in the schema. The description mentions module_code but does not add syntax, constraints, or selection guidance beyond what the schema provides.

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 clearly identifies the resource and output: an AI manifest plus guest/public read hints for one app identified by module_code. It distinguishes one-app inspection from the sibling list_guest_public_apps, but does not explicitly name alternatives or contrast with fetch_app_public_route.

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 phrase 'No Space JWT required' gives useful auth context, and 'guest/public read hints' implies the public/guest use case. However, it does not state when to use this tool versus list_guest_public_apps, fetch_app_public_route, or other public-app siblings.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by stating the allowlist/domain/path constraints and the 'No JWT' auth requirement, though it does not describe response or error behavior.

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 definition is one tightly written sentence, front-loaded with the operation and followed by the key constraints. Every clause adds necessary qualification with no wasted prose.

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 one-parameter read tool with rich annotations, the description covers the critical eligibility and auth constraints. It could be slightly more complete by noting the return shape or failure behavior, but the absence of an output schema makes that a minor gap.

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% and the single url parameter already has an example. The description adds value beyond the schema by specifying that the URL must be allowlisted, HTTPS, on *.apps.vtc.com, and contain /public, which are important call constraints not captured in the schema text.

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 uses a specific verb (GET) and resource (allowlisted HTTPS public API URL on *.apps.vtc.com) with clear scope constraints. It is clear what the tool does, but it does not explicitly differentiate itself from the many sibling public/search/list tools.

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 gives clear eligibility conditions: the URL must be allowlisted, HTTPS, on *.apps.vtc.com, include /public, and require no JWT. It does not name alternatives or state when not to use it, so it falls short of explicit routing guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description still adds real context beyond them: the call needs no authentication, and the result is an identifier intended to feed other public tools.

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?

Two short sentences, zero filler, with the core action leading and the return/chaining note trailing. Every clause carries information an agent cannot get from the schema or annotations alone.

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?

There is no output schema, so the description must say something about the return value — it names space_id but not what else comes back (name, handle, description, tags) or whether results are limited or paginated. Adequate for a single-parameter lookup, but slightly thin on result shape.

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% and there is only one required string parameter, so the schema already does the work; the description adds only a modest hint about which fields the query matches against. That is a baseline 3, not compensation for a gap.

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?

Specific verb plus resource: search the public VTC Space directory, with the searchable fields (name, handle, description, tag) enumerated. It does not differentiate from the near-identical sibling search_public_spaces, so an agent still has to guess which search entry point to pick.

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?

"No login" and "returns space_id for the other public tools" imply usage (unauthenticated discovery, chaining into other public tools), but there is no explicit when-to-use-this-vs-sibling guidance despite search_public and search_public_spaces sitting right next to it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered without the description. The description adds value by enumerating what the payload contains (public-facing fields plus guest-facing AI Support modes), but says nothing about what happens with private/invalid spaces or how guest-view visibility is scoped.

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?

One sentence, no filler, with the resource front-loaded and the returned facets in a compact parenthetical. Nothing here could be removed without losing information.

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?

With one fully documented parameter, rich annotations, and no output schema, the description does the necessary remaining work by telling the agent what comes back. A brief note on invalid/unresolvable space behavior or the guest perspective would make it complete.

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 description coverage is 100% and the single 'space' parameter already documents accepted forms (name, @handle, numeric id) with a concrete example. The description adds no additional parameter semantics, so the baseline 3 applies.

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 names the resource precisely ('Public profile of one Space') and enumerates the returned facets (description, website, networks, AI Support modes), which lets an agent distinguish it from list/search siblings like list_space_public_documents or search_public_spaces. It stops short of explicitly naming the sibling it complements (e.g., find_space for resolving a name first), so it is clear but not fully differentiated.

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?

Usage is only implied: 'of one Space' signals a single-entity lookup rather than a search, which is the right cue. But there is no explicit when-to-use guidance, no mention of resolving a space name via find_space first, and no stated preconditions for the single required argument.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description contributes the useful addition that no authentication is required and that the catalog is public, but says nothing about result size, pagination or what an entry contains.

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?

One short sentence with no filler, and the 'public/no auth' qualifier is placed where it will be read first. Nothing is repeated from the title or annotations.

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?

With no parameters and rich annotations, the main remaining need is a hint at what the catalog returns, since there is no output schema. The description gestures at 'app-facing API services' but leaves the shape and scope of the result implicit.

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?

The tool takes zero parameters, so the baseline is 4. There is nothing about arguments the description could reasonably add.

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?

States a specific verb+resource: a public catalog of app-facing API services. 'ZAPI developer catalog' distinguishes it from the sibling list tools, which surface apps, documents, spaces and people rather than API services. The jargon 'ZAPI' and 'app-facing' keep it from being fully self-explanatory.

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?

No statement of when to use this versus the many sibling public-listing tools, and no exclusions or prerequisites beyond '(no auth)'. The agent must infer that this is the discovery entry point for API services.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real context beyond them: it operates over the public ZAPI and requires no Space JWT, which tells the agent about the auth model.

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?

Two short sentences, zero waste, with the resource and filter front-loaded and the auth constraint appended where it belongs.

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 read-only filtered list with complete schema coverage and no output schema, the description covers scope and auth adequately. The only gap is that it does not indicate what an app entry contains, but for a list tool with annotations this is minor.

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 description coverage is 100% and the single group_id parameter is fully documented, including omission after set_guest_context. The description adds nothing further about the parameter, so the schema carries the load — baseline 3.

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?

States a specific verb (list) plus resource (apps on a Space dashboard) with a filtering condition (public_guest_access=yes). It distinguishes itself reasonably from the other list_*_apps siblings via the guest-browse scoping, though it does not name them explicitly.

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?

Usage is implied by the filter condition and the 'no Space JWT' note, which signals when this route is usable. There is no explicit when-not guidance or named alternative (e.g. list_network_public_apps), leaving selection inference to the agent.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds the useful behavioral fact that results are scoped to network membership and gives a concrete example (network id 1 = VTC), but says nothing about result size, ordering, or pagination.

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?

One short sentence with no filler and the scoping information front-loaded. It is efficient, though the missing verb slightly weakens the opening.

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?

With no output schema, the description does state what is returned (a public app catalog) and for whom, and annotations cover safety and world scope. For a one-optional-parameter read tool this is nearly sufficient, with only return-format and default-behavior details missing.

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 0% for the single network_id parameter, so the description carries real weight here; it clarifies that the id denotes a VTC network and gives '1' as VTC, which meaningfully supplements the bare string/pattern/default schema. However, it does not explain what other network ids mean or what happens if the parameter is omitted (default behavior).

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 identifies the resource ('public app catalog') and its scope ('shown to members of a VTC network'), but it is a noun phrase with no verb, so the agent must infer 'list' from the tool name. It also does not distinguish this from close siblings such as list_guest_public_apps or list_developer_catalog, leaving the catalog's identity ambiguous.

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?

There is no statement of when to call this versus the many sibling catalog/search tools, and no mention of prerequisites or exclusions. The only guidance is the parenthetical example network id, which is about a parameter, not usage.

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

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

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful auth and access context with 'No JWT' and 'public-read', but it does not disclose error behavior, pagination, or other operational details beyond the annotations and schema.

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 very short and front-loads the core action. It is efficient, though the fragmentary wording and unexplained 'ZAPI' jargon slightly reduce clarity.

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?

Given high schema coverage and existing annotations, the description is minimally adequate. However, it lacks sibling discrimination and does not describe return behavior, which matters more because there is no output schema.

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 description coverage is 100%, so parameter meaning is already fully documented in the schema. The description only implies collection selection and public-read access, adding little parameter-specific guidance beyond the structured fields.

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?

States a specific verb and resource: read documents from a collection marked public-read, with no JWT. It is clear what the tool does, though it does not explicitly distinguish itself from similar siblings like list_space_public_documents or read_public_collection.

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 implies usage for public-read collections without JWT, but it does not explicitly say when to use this tool instead of its similar siblings or when not to use it.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful expectation-setting with '(names and types only)', but says nothing about ordering, pagination, permissions, or behavior when the Space has no public AI Support.

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?

One sentence, front-loaded with the verb and resource, and the parenthetical return-scope detail earns its place. No filler.

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 read-only, single-parameter list tool with full schema coverage and complete annotations, this is close to sufficient; the names-and-types note sets return expectations despite no output schema. Minor gaps remain around result ordering, empty results, and whether authentication is needed to see public AI documents.

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 description coverage is 100%; the single 'space' parameter is already documented with accepted forms (name, @handle, numeric id) and an example. The description adds no meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb (List) and a specific resource (documents used by a Space's public AI Support), and adds that only names and types are returned. It implicitly distinguishes itself from sibling list_public_collection_documents by scoping to AI Support rather than collections, but it never names that sibling or explicitly contrasts the two.

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 phrasing 'a Space's public AI Support uses' implies when the tool is relevant, but there is no explicit when-to-use/when-not guidance and no naming of alternatives such as list_public_collection_documents. Usage must be inferred from the resource description.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond them: the access model is public-read only, and the text filter is 'matched over the returned rows', which signals post-fetch filtering rather than a server-side query — an important behavioral detail that affects result interpretation.

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?

Three compact sentences with the access restriction front-loaded and the failure message last. No filler, though the private-collection error string is a bit of a detail that could be tightened.

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?

With no output schema and 4 parameters, the description should do more to describe what a returned row looks like and how paging interacts with the text filter. It covers access scope and filter semantics adequately but leaves the caller guessing about pagination and the two undocumented parameters.

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 50%: space and text are documented in the schema, while collection and page_size are not. The description clarifies the filter semantics ('matched over the returned rows') but says nothing about collection naming expectations or what page_size controls, so it only partially compensates for the coverage gap. Baseline 3 given partial schema 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?

States a specific verb (Read) and resource (documents from a Space collection), with the key qualifier that only collections explicitly shared as public-read are visible. The scoping constraint separates it from generic document readers, but it never names or contrasts the very similar siblings list_public_collection_documents and list_space_public_documents, leaving the agent to guess which one to call.

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?

Use context is implied (you want documents out of a public collection) and the failure mode for private collections is stated, which helps the agent interpret an empty/not-found result. However there are no explicit when-to-use/when-not rules and no reference to the near-duplicate sibling tools, so selection guidance 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.

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.

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

Annotations already declare this as a safe idempotent read-only operation. The description adds useful behavioral context beyond annotations: no authentication, exclusions for opted-out/private users, and the fact that email is not searchable.

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 compact and front-loaded with the core search behavior. Every clause adds a useful constraint or clarification, with no wasted prose.

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 complete schema coverage and annotations, the description covers purpose, auth, and key coverage limits. It does not describe result format or ordering, but the tool is simple enough that this is a minor gap.

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 the schema already documents both q and limit. The description reinforces username search and the optional @, and adds that email is not searchable, but it does not add meaningful detail about the limit parameter beyond the schema.

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 resource: find public people by username. It distinguishes this from broader public-search siblings by naming the searched entity and the username search key, including the optional leading @.

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?

It gives clear usage context: no login is required, email is not searchable, and opted-out/private-network people are omitted. It does not explicitly name sibling alternatives, but the constraints make the intended use clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful context by stating the search requires no login and that the returned id is intended for set_guest_context, though it does not discuss rate limits or result pagination.

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 short sentences with no wasted text. The primary search purpose is front-loaded, followed immediately by the relevant downstream usage instruction.

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 public search tool with rich annotations and full schema coverage, the description supplies the key missing context: no login is needed and the returned id feeds set_guest_context. It does not describe the result list shape, but no output schema exists and the core invocation needs are covered.

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 description coverage is 100%, so the schema already documents both parameters. The description reinforces that q accepts a space name or username/slug, but it adds little beyond the schema and does not clarify the limit parameter.

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 uses a specific verb and resource: 'Find public VTC Spaces by space name or space username/slug.' It adds useful qualifiers such as '(no login),' but it does not distinguish this tool from siblings like find_space or search_public.

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 gives a downstream usage hint: 'Use the returned id with set_guest_context.' However, it does not explain when to use this tool versus alternatives such as find_space or search_public, nor does it state exclusions.

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

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

Annotations already declare readOnly, idempotent, and non-destructive, so safety is covered; the description adds useful context the annotations don't carry — that this operates without login and only succeeds when the input resolves to exactly one public space. It stops short of saying what happens on ambiguity (error vs. first match), leaving one behavioral gap.

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?

Two sentences with the action and scope front-loaded, followed by the disambiguation rule. No filler, no repetition, and the alternative is placed after the primary action where it belongs.

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 single-parameter tool with rich annotations and no output schema, the description covers purpose, accepted formats, and sibling routing. The only missing piece is failure behavior when the name matches zero or multiple spaces, which an agent would otherwise have to discover by trial.

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 description coverage is 100% and the parameter description already enumerates 'Numeric Space id, public slug (dexi), or a unique space name.' The tool description restates the same three accepted forms, adding only the implicit uniqueness requirement, so it largely duplicates structured data. Baseline 3 applies.

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?

States a specific verb and resource ('Bind a Space for guest/public tools') and immediately scopes it to the unauthenticated/public surface with '(no login)'. This distinguishes it from siblings like search_public_spaces or find_space without requiring the agent to open either schema.

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?

Gives an explicit routing rule: 'Prefer search_public_spaces when the name may match several spaces,' naming the alternative and the condition that selects it. Combined with the 'matches one public space' constraint, an agent knows both the happy path and the fallback.

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