appforshare-mcp

Official

Overview Schema Source Related Servers Discussions Admin

Create a per tester access code

create_access_code

Generate a one-off access code for a build install page or extra link, with a label and device limit, so testers can install without using the shared password.

Instructions

Make a one off access code for a build's own page or for one extra link, with a label (the client or person it is for) and a device count (1 to 50, default 1). A tester types it on the install page instead of the shared password; each install takes one device off the code. Returns the code once: give it to the person, it cannot be shown again. Ask the person first and pass confirm: true. Team, Owner or Admin role.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "target": "<target>",
      "label": "<label>",
      "confirm": "<confirm>"
    },
    "name": "create_access_code"
  }
}

Input Schema

Name	Required	Description
`label`	Yes	Who it is for, for example Ana at Client A (testers do not see it)
`target`	Yes	Build id, build slug, or the slug of an extra link
`confirm`	Yes
`maxInstalls`	No	Devices the code may install on (default 1)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.7Nov 13, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations (readOnlyHint false, idempotentHint false), it discloses the critical one-way behavior: the code is returned once and can never be shown again, so it must be handed over immediately. It also explains the install accounting ('each install takes one device off the code') and the permission tier required, which the annotations cannot convey.

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

Conciseness4/5

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

Front-loads the purpose, then the consumption model, then the safety precondition and role; every sentence carries information. The nested parentheticals make it a dense run-on that is slightly harder to scan than it needs to be.

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

Completeness5/5

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

With no output schema, the description correctly covers the return value (a single code shown once), the mutation side effects, the role requirement, and the confirmation gate. For a 4-parameter creation tool with 75% schema coverage, an agent has everything needed to call it correctly.

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 75%, and the description adds meaning for the undocumented `confirm` parameter by tying it to asking the person first, and clarifies the device count parameter (1 to 50, default 1) and what `target` accepts. The label explanation largely restates the schema's own description, so it doesn't add much beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Make a one off access code') plus the exact scope ('for a build's own page or for one extra link') and the mechanism (tester types it instead of the shared password). An agent can distinguish this creation tool from revoke_access_code or list_access_codes from the verb alone.

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

Usage Guidelines4/5

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

Gives a clear precondition ('Ask the person first and pass confirm: true') and a role requirement ('Team, Owner or Admin role'), which tells the agent when it is allowed to call it. It stops short of naming alternatives or stating when-not to use it, e.g. when a shared password or tester group is preferable.

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