open77_permissionsLook up a single Open77 permission or the entire list, showing what it gates, which natives use it, and which guides declare it for manifest permissions blocks.
One permission (what it gates, which natives, which guides declare it) or the whole list. These are the strings a manifest's permissions { } block declares.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a safe read-only operation, and the description adds useful behavioral context by describing the kind of data returned (permission gating, native references, guide declarations). It does not contradict the annotations and gives the agent a preview of output semantics.
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 with no filler. The core behavior is front-loaded, and the clarification about manifest permission strings is immediately useful. Every phrase earns its place.
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 tool with one optional read-only parameter, the description is mostly complete: it states what the tool returns and the general input/output relationship. There is no output schema, so a bit more detail about response shape could help, but the behavior is simple enough that an agent can likely call it correctly.
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 schema provides no description for the 'name' parameter (0% coverage), so the description must carry meaning. It partially does by implying that a named permission returns details and an omitted name returns the whole list. However, it never explicitly states that 'name' is the permission name or that omitting it yields the full list, leaving some inference required.
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 clear resource type ('manifest permissions') and what the tool returns: either a single permission with details on what it gates, which natives, and which guides declare it, or the whole list. It does not explicitly contrast itself against sibling tools, but the purpose is specific enough to be understood.
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 guidance about when to use this tool versus alternatives like open77_manifest_schema or open77_guide. The phrase 'or the whole list' implies the optional name selects one item vs. all items, but this is not stated as a decision rule. No exclusions or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.