Skip to main content
Glama

Who can open the app

access

Show or change who can open an internal app: everyone at the company, a restricted list, or specific people added or removed by work email.

Instructions

Shows or changes who can open the app. "show" (default), "everyone" (everyone at the company), "only" (only these people and the owner), "add" or "remove" people on that list.

Input Schema

NameRequiredDescriptionDefault
actionNoWhat to do
emailsNoWork email addresses
directoryNoAbsolute path of the app's folder (the one with teamonly.json). Defaults to the folder the server started in.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.6.0

TDQS

B3.4/5.0
Behavior2/5

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

Annotations only declare openWorldHint; they do not declare readOnly or destructive behavior. The description signals that this tool can change access and enumerates add/remove modes, but it omits permission requirements, reversibility, immediate effect, and other mutation side effects, leaving a significant gap for an access-control mutation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two tight sentences, front-loads purpose, then maps the action values without repetition. Every phrase contributes to selecting the right action.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a fully described schema and no output schema, the description covers the core use and action modes. However, for a tool that can change app access, it does not state authorization requirements or the consequences of changing the list, leaving meaningful context gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description adds real meaning for the action enum: show is default, everyone means company-wide, only means named people plus owner, and add/remove operate on that list, which is more than the schema's 'What to do'.

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?

It states a specific resource and pair of operations ('Shows or changes who can open the app') and enumerates the action modes. It does not name or differentiate from siblings such as roles or get_app_rules, so it stops short of 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explains what each action value does, including show as default and the difference between everyone and only. It gives no explicit when-to-use/when-not guidance versus sibling tools, so the agent must infer tool selection.

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