Skip to main content
Glama

NoMac

by app.nomac
OverviewDiscussionsAdmin

Ask the person for a secret

request_secret

Creates a link where the human enters a secret in their browser, so its value never passes through the chat: a token, a .env value, a .p12 or a config file. The link works once, within 24 hours, with no NoMac account. Once entered, new Macs receive it, and install_secrets puts it on a running one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindYesvariable: one line of text, set as an environment variable on the Mac; file: any bytes, stored as a file
nameYesA variable's name (letters, digits, underscores, like SENTRY_AUTH_TOKEN) or a file's name (like GoogleService-Info.plist)
deliveryNoevery_mac (default) or on_request: only when install_secrets names it
descriptionYesWhat the person should enter and why, in plain words; shown to them on the page
destinationNoFiles only: where on the Mac, like ~/.netrc

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedOutput schema / (root)
      Previous value: -{
-  "$schema": "http://json-schema.org/draft-07/schema#",
-  "additionalProperties": {},
-  "description": "The JSON response of the NoMac API for this operation",
-  "properties": {
-    "error": {
-      "additionalProperties": {},
-      "description": "Present only when the call failed",
-      "properties": {
-        "code": {
-          "description": "Stable machine-readable error code, for example insufficient_credit",
-          "type": "string"
-        },
-        "message": {
-          "description": "What went wrong and what to do next",
-          "type": "string"
-        }
-      },
-      "required": [
-        "code",
-        "message"
-      ],
-      "type": "object"
-    }
-  },
-  "type": "object"
-}New value: +null
  2. Added

TDQS

A4.4/5.0
Behavior5/5

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

Annotations only declare the generic safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false). The description goes well beyond them with lifecycle facts an agent could not otherwise infer: the link is single-use, expires in 24 hours, requires no account, and its value never transits the chat.

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?

Two dense sentences, zero filler. The core mechanism (browser link, never through chat) is front-loaded, and the delivery behavior follows in the second sentence where it belongs.

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

Completeness4/5

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

For a multi-step, asynchronous human-in-the-loop tool with no output schema, the description covers the important mechanics: what is produced, its lifetime, who receives it, and the follow-up tool for running Macs. The one gap is not stating what the agent receives back (presumably the link to hand to the human), which is the agent's immediate next step.

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

Parameters3/5

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 every parameter, including both enums and the destination field. The description's concrete examples (token, .env value, .p12, config file) loosely illustrate the kind enum but add no syntax or format detail 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.

Purpose5/5

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

The description states a specific action and artifact: it 'Creates a link where the human enters a secret in their browser,' and immediately distinguishes this from the sibling install_secrets, which 'puts it on a running one.' An agent can tell this apart from the exec/write/read siblings without inspecting any schema.

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?

It gives clear contextual routing: new Macs automatically receive the secret, while already-running Macs require install_secrets. It does not state explicit exclusions versus siblings like mac_input for one-off prompts, but the use context (out-of-band secret entry, never through chat) is unambiguous.

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

All NoMac toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources