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

The description does supply useful operational context beyond annotations: a per-call cost ('3 MESH/call') and a visibility constraint ('public or caller-permitted view only'). However, it asserts 'Read-only, changes nothing', while the supplied annotations declare readOnlyHint=false, i.e. the tool is not declared read-only — a direct conflict that could mislead an agent about side effects.

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 compact sentence with the scope list front-loaded, plus a short qualifier clause. Minor waste in repeating the tool name verbatim at the start and in the cryptic trailing '(3 MESH/call, a tool · ops)' fragment, but nothing is padded.

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 live access-audit tool with a single opaque nested payload and no output schema, the description leaves out what must be passed to identify the target place and what the returned data looks like. The ambiguous read-only claim further weakens completeness for a tool whose core value is an accurate current-state picture.

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?

There is a single required nested 'input' object whose schema description is generic boilerplate about agent-brain/agent-memory payloads and says nothing about what this tool expects. The description speaks of 'any place' but never states that an identifier for that place must be supplied, nor in what form, so it does not compensate for the irrelevant 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 states a specific verb and resource: it checks a place's live access across members, teams, rules, bypass list and installed apps, and clarifies the answer surface ('who is in, who can bypass what, and what is open'). It does not differentiate itself from plausibly overlapping siblings such as board-access-guard, org-profile-check or mesh-audit-external-posture, and 'place' is never defined as a channel, board, workspace or org.

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 explicit when-to-use, when-not-to-use, or named alternative. The phrase 'public or caller-permitted view only' hints at an authorization precondition but does not tell the agent which situations call for this tool rather than a sibling guard/audit tool.

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