Skip to main content
Glama

Remember a node's admin password

set_credential
Idempotent

Store a password for a node to enable authenticated admin and health commands. Use when you have the admin password out-of-band; overwrites previous credentials.

Instructions

Persist the password the server will use to log into node for subsequent admin and remote get_node_health calls. Use this when you've learned a repeater's password out of band (e.g. via DM) and need the server to remember it across restarts. This is the server's local credential, not the node's password — it does not send anything over the mesh. The node must already be known (in the contact list) — a typo'd name is rejected so credentials don't silently land under a key that's never looked up. Overwrites any existing entry. The password (max 256 chars) is stored in the credentials file under MESHCORE_STATE_DIR with 0600 permissions, and is never echoed in the tool result. The password is opaque to the server: the device unlocks guest (read-only) or admin (full) depending on which it matches — store the admin password when you have it, since it covers reads too. If a later admin command comes back with ERR: in reply, the stored credential is likely guest-tier; overwrite via set_credential if you have the admin password. Separate from the set-admin-password admin command (which changes the node's own password).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeYescontact name or hex public-key prefix of the node — must already be in the device's contact list (a typo'd node is rejected)
passwordYesthe login password the server should use for this node (max 256 chars)

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
nodeYes
storedYes
Behavior5/5

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

Discloses overwrite behavior, storage details (file, permissions, no echo), guest vs admin tiers, and failure recovery (ERR reply), adding context beyond annotations which already convey idempotency.

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?

Well-structured and front-loaded, but slightly verbose with extra detail on admin/guest; still every sentence serves a purpose.

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?

Thoroughly covers behavior, constraints, edge cases (typo, ERR recovery), and interplay with admin/get_node_health, fully equipping the agent.

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

Parameters5/5

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

Adds meaning beyond schema: node must be in contact list, password max 256 chars, explains admin/guest implications, which the schema's descriptions only hint at.

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 explicitly states the tool persists a password for admin and health calls, clearly distinguishing it from siblings like forget_credential and set-admin-password.

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

Usage Guidelines5/5

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

Provides explicit when-to-use (out-of-band password learning) and when-not (typo rejection, not node's own password), with clear differentiation from related commands.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dpup/meshcore-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server