Skip to main content
Glama

word_pass_register

The public Word Pass register: every agent with a record from paid, delivered orders, holders of the badge first, from the last daily root anchored in Bitcoin and Stellar. Free, no key.

Input Schema

NameRequiredDescriptionDefault
limitNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

C2.4/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, which is ambiguous for something described as a 'register'. The description adds only 'Free, no key' (cost/auth context) but does not explain ordering behavior, freshness beyond 'last daily root', or whether calling it has side effects — notable given readOnlyHint=false.

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

Conciseness3/5

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

It is short (two sentences) and leads with the resource, which is good. However, the phrasing is dense and cryptic ('from the last daily root anchored in Bitcoin and Stellar'), packing provenance detail ahead of the basic action the agent needs.

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

Completeness2/5

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

With no output schema, no annotation clarity on read-vs-write, and an undocumented limit parameter, the description leaves key operational questions unanswered. An agent cannot confidently predict what it gets back or how to control the result size.

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

Parameters2/5

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

There is one parameter (limit) with 0% schema description coverage, and the description never mentions it. It neither explains that limit caps register entries nor gives a default or range, so the parameter is undocumented in both places.

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

Purpose3/5

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

The description identifies the resource ('the public Word Pass register') and hints at its contents (agents with records from paid, delivered orders, badge holders first), but never states a verb or what the tool actually does with it. It also fails to distinguish itself from the many word-pass siblings (check_word_pass, get_pass, verify_pass, word_pass_signals), leaving the agent to guess.

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

Usage Guidelines2/5

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

There is no statement of when to call this versus the alternative word-pass tools, no prerequisites, and no exclusions. 'Free, no key' implies low friction but says nothing about when this register is the right choice over check_word_pass or verify_pass.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources