Skip to main content
Glama

Check in as a Humanity Loop contributor node

contributor_checkin

Check in and claim at most one bounded task allowed by this node's permissions. Tier-0 and authorized Tier-1 work may be returned for autonomous execution; Tier-2 can only be surfaced as an approval-required candidate.

Input Schema

NameRequiredDescriptionDefault
hostNo
languagesNo
node_tokenYes
capabilitiesNo
user_agent_labelNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.1/5.0
Behavior3/5

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

With no annotations, the description carries the full burden and does disclose real behavior: one task per call, permission-bounded selection, and tier-based routing (Tier-0/1 returned for autonomous execution vs Tier-2 surfaced as approval-required). It omits auth semantics for node_token, rate limits, and what happens when no eligible task exists.

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?

Two dense sentences with the primary action front-loaded and the tier caveat following immediately; no filler. Slightly jargon-heavy but appropriately sized.

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?

For a 5-parameter tool with no annotations and no output schema, the description covers only the tier routing rule and says nothing about the identity/host/capability inputs or the shape of the returned task candidate, leaving an agent under-informed.

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?

Schema description coverage is 0% and the description mentions no parameter by name. 'This node's permissions' hints that node_token/capabilities matter, but host, languages, and user_agent_label are left entirely unexplained in both schema and description.

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?

States a specific verb pair (check in, claim) and a bounded resource (at most one task scoped to this node's permissions), which is distinct from siblings like contributor_submit or contributor_set_status. The tier vocabulary is domain-specific but the core action is unambiguous.

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?

Implied usage is clear (this is the claim/poll operation for a registered node), and it explains what happens to work of each tier, but it never says when to prefer this over contributor_submit or contributor_set_status, nor what prerequisites (registration, status) must hold first.

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.