Skip to main content
Glama

plainhub_agent_check

Checks this PC is ready to start Your agent by verifying Node.js, Claude Code, plainhub, free ports, running agents, paired browsers, and saved GitHub token, then reports fixes and the command to run.

Instructions

Check this PC before the person starts "Your agent" (plainhub agent): Node.js, Claude Code and its version, the plainhub command, free ports and an agent already running, paired browsers, and whether a GitHub token for the phone is saved. It changes nothing: it starts nothing except claude --version, never reads a token's value, and does not start the agent. Each problem comes with one line on how to fix it; when all is ready, the last line is the command the person runs in their own terminal. Use it first when the user wants to set up Your agent or ask Claude Code from their phone, and again after fixing something. Example: {}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.8.0

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations supplied, the description carries the full behavioral burden and does so well: it states the tool changes nothing, starts nothing except `claude --version`, never reads a token's value, and does not start the agent — a precise side-effect profile that an agent could not infer from the empty schema. It also discloses output shape (one fix line per problem, final line is the command to run).

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?

The purpose and the no-side-effects guarantee are front-loaded, and each remaining clause adds a checklist item or a safety fact. It is a dense run-on paragraph, though, with slightly awkward quoting around "Your agent" that costs some readability.

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?

There is no output schema, and the description compensates by explaining the result format — per-problem remediation lines and a final runnable command — plus the readiness condition. For a zero-parameter diagnostic tool this is complete enough to call and interpret without further information.

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?

The tool takes zero parameters, so the baseline is 4; the description correctly notes the invocation example is `{}`, confirming no arguments are needed. No further parameter meaning is required.

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?

"Check this PC before the person starts Your agent" gives a specific verb and resource, and the description enumerates exactly what is inspected (Node.js, Claude Code version, plainhub command, free ports, running agent, paired browsers, GitHub token). It's clear what the tool does, though it never explicitly names a sibling tool it should be preferred over, leaving the distinction from plainhub_open/plainhub_auth to be inferred from usage context.

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?

"Use it first when the user wants to set up Your agent or ask Claude Code from their phone, and again after fixing something" gives a clear trigger and a re-run condition. There is no explicit when-not guidance or named alternative, which keeps it at 4 rather than 5.

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