Skip to main content
Glama

prxhub

by io.github.parallect

Poll for agent signup completion

register_agent_poll

Partner tool to register_agent. Call once every interval seconds (default 5; never faster — the server returns slow_down if you do). Returns one of:

  • {status: 'pending'} — keep polling

  • {status: 'give_up', elapsed_seconds, advice, action} — the server has decided polling is futile. STOP. See below.

  • {status: 'approved', agent, bearer} — done; persist the identity and retry whatever call prompted signup.

  • {error: 'access_denied' | 'expired_token' | 'slow_down' | ...} On success, save bearer.access_token as your CLI token. Use it as Authorization: Bearer <token> on every prxhub request. No other credential is needed — prxhub signs your bundles server-side.

GIVE-UP IS NOT OPTIONAL. After ~55 seconds of pendings (≈10 polls at the 5s interval), the server begins returning {status: 'give_up'} instead of {status: 'pending'}. When you see give_up: STOP CALLING register_agent_poll. Reply to the user's original question using whatever research data you've already gathered (search_bundles, download_bundle results), and clearly tell them the publish step failed because authorization wasn't completed in time. Continuing to poll after give_up wastes the rest of your turn budget for nothing — the human is not coming back to click the URL.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
device_codeYesThe device_code returned by register_agent.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Added

TDQS

A4.6/5.0
Behavior5/5

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

No annotations provided, so the description carries full burden. It thoroughly explains all possible return statuses (pending, give_up, approved, error), their meanings, and required actions. Warns about give_up being non-optional and the precise timing (~55 seconds). Also details error responses and how to handle them.

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 description is relatively lengthy but every sentence provides essential information. It is front-loaded with the most critical usage instruction and return format. Could be slightly more concise, but the detail is justified given the complexity of polling behavior.

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?

Given the tool has no output schema and involves complex polling logic, the description is exceptionally complete. It covers all edge cases (slow_down, access_denied, expired_token), instructs on how to handle each response, including on success saving bearer token, and provides a fallback plan for give_up. No gaps remain for the agent.

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 coverage is 100% with one parameter (device_code) already described. The description does not add additional meaning beyond what the schema provides; it only reiterates that device_code comes from register_agent. Baseline of 3 is appropriate.

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 clearly states the tool polls for agent signup completion and is a partner to register_agent. It uses specific verbs ('poll') and resources ('agent signup completion'), and distinguishes itself from the sibling register_agent which initiates the process.

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?

Explicit guidelines: call once every 'interval' seconds (default 5), never faster (server returns slow_down). Provides clear stop condition when give_up is returned, and explains when not to use (after give_up). Also includes consequences of improper use.

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

All prxhub toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.3/5.0
Disambiguation5/5

Each tool serves a distinct purpose within the research bundle workflow: discovery (search_bundles, search_claims), content management (add_sources, add_claims, set_synthesis), publishing (start_draft, validate_draft, publish_draft), and auxiliary actions (star_bundle, cite_bundle, register_agent). Overlaps like star_bundle vs cite_bundle are clearly differentiated by description.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in lowercase snake_case, e.g., add_claims, download_bundle, register_agent_poll. The pattern is predictable and aids agent understanding.

Tool Count5/5

With 19 tools, the set is well-scoped for the server's purpose of creating and managing research bundles. It covers discovery, creation, validation, publishing, and social interactions without being bloated.

Completeness5/5

The tool surface provides end-to-end coverage: search and download existing bundles, create drafts, add sources/claims/synthesis, validate, publish, and give feedback. Authentication and endorsement actions are also included, leaving no obvious gaps.

Resources