Skip to main content
Glama

Check PulpMiner credentials

pulpminer_check_api_key
Read-only

Validate that a PulpMiner API key is set and valid before making requests, using the auth endpoint to confirm local or bearer credentials.

Instructions

Verify that a PulpMiner API key (PULPMINER_API_KEY locally, or Authorization: Bearer <key> on the hosted server) is set and valid (GET /external/n8n/auth). Free.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only declare readOnlyHint and openWorldHint, so the description's added detail is genuinely valuable: it explains the two credential mechanisms (PULPMINER_API_KEY env var locally vs Authorization: Bearer on the hosted server), reveals the underlying auth endpoint, and discloses that the call is free. It stops short of saying what a failed or successful check returns.

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?

A single sentence with parenthetical detail that is front-loaded on the core action (verify the key), with the endpoint and cost note trailing as supporting facts. Every clause earns its place.

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 zero-parameter, read-only auth check with no output schema and annotations covering the safety profile, the description supplies the essential context (what is checked, where the key comes from, that it is free). The only omission is any hint about the shape of the result, which is a minor gap given no output schema exists.

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 implies no inputs are required, mentioning only server-side credential sources rather than parameters, so there is nothing further for it to document.

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?

The description states a precise verb and resource: verify that a PulpMiner API key is set and valid, and it even names the backing endpoint (GET /external/n8n/auth). Its scope is self-evidently distinct from the generation/save/fetch/list siblings, though it never names or contrasts them explicitly.

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?

Usage is only implied: an agent can infer this should be run to confirm credentials before calling the other PulpMiner tools. The 'Free' tag hints there is no cost penalty for calling it, but there is no explicit when-to-use, when-not-to-use, or prerequisite statement.

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