Humanity Loop

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.

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.

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.

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.

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.

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.

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

With no annotations, the description carries full burden. It usefully discloses pseudonymity, default tier autonomy with audit trail, Tier-2 human approval, and a one-time private node token. However, it omits auth requirements, idempotency, error behavior, and side effects beyond token issuance.

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

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

Three tight sentences with zero filler. The purpose is front-loaded, followed by important behavioral notes. Every sentence earns its place and the description is appropriately sized for the tool's complexity.

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

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

Given 8 parameters, 0% schema description coverage, no annotations, and no output schema, the description is incomplete. It mentions the return token and some tier behavior, but does not compensate for the missing parameter semantics or auth prerequisites required for a registration tool.

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

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

Schema description coverage is 0% and the description mentions none of the 8 parameters. Critical fields like risk_permissions (with its tier enum), allow_tier1_review, and setup_email_consent are left entirely undocumented, forcing the agent to rely solely on raw JSON schema.

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

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

The description states a specific verb ('Create') and resource ('pseudonymous Humanity Loop contributor node'), making the tool's core purpose clear. It does not explicitly name or differentiate from sibling tools like contributor_checkin or contributor_submit, but the resource is distinct enough for an agent to distinguish it.

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

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

No guidance is given on when to use this tool versus alternatives, nor are prerequisites or required conditions mentioned. The description implies registration but offers no explicit when-to-use or when-not-to-use context relative to sibling contributor tools.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely important trait: revocation is permanent for the token. It also signals owner-only authorization implicitly via 'Owner control'. However, it says nothing about what pause/resume do to the node's behavior, whether they are reversible, or any auth/rate mechanics.

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

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

Two short sentences, front-loaded with the actor and scope, no filler. It is efficient, though the second sentence could be better anchored to the revoke action rather than 'Revocation' in the abstract.

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

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

For a mutation tool with zero annotations, no output schema, and 0% schema coverage, the description is under-specified. It omits the distinction between the three actions, the meaning of node_token, and any post-condition, leaving an agent without enough to invoke confidently across all three modes.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does not. The enum supplies the action values (pause/resume/revoke) and aligns with the title, but node_token is never explained — no hint about what the token identifies or where it comes from. Only partial compensation for the coverage gap.

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

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

The title states a specific action set (pause, resume, revoke) on a specific resource (contributor node), and the description reinforces the actor ('Owner control'). Combined, an agent can distinguish this from siblings like contributor_register or contributor_checkin. The description alone is a bit thin ('owner control'), leaning on the title for the verb.

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

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

No guidance on when to choose pause vs resume vs revoke, no prerequisites, and no mention of alternatives among the sibling tools. The enum lists the actions but the description never explains which situation calls for which.

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

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

With no annotations, the description carries the full burden, and it does disclose genuinely useful lifecycle behavior: submissions enter Humanity Loop review before becoming canonical state, and Tier-1 actions need receipts. It omits other important traits such as authentication via node_token, idempotency/resubmission behavior, and what happens to a failed submission.

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

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

Three tight sentences with the action front-loaded and each sentence carrying a distinct payload (purpose, receipt requirement, review gate). Mild jargon ('Tier-1', 'Humanity Loop') costs a point but nothing is padded.

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

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

For a 6-parameter mutation tool with a nested object, no annotations, and no output schema, the description is thin. It never explains how node_token is obtained, what the result object must contain, or what the caller receives after review, leaving the agent unable to call it confidently.

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

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

Schema description coverage is 0% across 6 parameters, including a nested result object, so the description must compensate and largely does not. It touches evidence, uncertainty, and implicitly result and receipt, but leaves node_token, work_id, and failure_modes entirely undefined in either place.

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

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

States a specific verb ('Submit') and resource ('a claimed contributor task result'), and adds the key qualifiers evidence and uncertainty. It does not, however, distinguish itself from the sibling contributor_* tools (checkin, register, set_status), so an agent must infer the boundary rather than read it.

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

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

Usage is only implied: an agent infers it is called after claiming a task and before review. The one explicit conditional ('Tier-1 external actions should include a verifiable receipt') gives partial content guidance, but there is no statement of when not to use it or which sibling to prefer for adjacent operations.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Get' implies a safe read, but nothing is said about what happens when the ID is unknown, whether results are cached, or what the returned action contains.

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

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

One front-loaded sentence that identifies the resource, the key, and an example with zero filler. Nothing could be trimmed without losing information.

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

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

For a simple one-parameter read with no output schema, the description covers the essentials, but it omits error/not-found behavior and any routing hint against list_actions. It is adequate but leaves visible gaps.

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

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

Schema coverage is 0% and the schema only declares a non-empty string, so the description must compensate — and it does by naming the parameter's meaning ('ledger ID') and supplying a concrete format example ('HL-042'). That is meaningful added value for a single-parameter tool.

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

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

States a specific verb ('Get') and singular resource ('one Humanity Loop action'), with the retrieval key ('by ledger ID') made explicit. It implicitly contrasts with list_actions, though it never names that sibling or explains the distinction directly.

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

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

There is no when-to-use guidance and no reference to alternatives such as list_actions, which retrieves the same resource in bulk. The agent must infer that this tool is for single-record lookup by ID.

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

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

With no annotations, the description carries the full burden. It usefully discloses that only public projects are returned, and 'Read' implies a non-mutating operation, but it says nothing about behavior on a missing/private slug or what authentication, if any, applies.

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

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

A single eight-word sentence with no filler, front-loading the verb and resource so the agent grasps the operation immediately.

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

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

For a simple read-one getter this is adequate minimum-viable coverage, but with no annotations and no output schema, the description should at least indicate the error behavior for an unknown slug or what the returned card contains.

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

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

Only one parameter exists and schema coverage is 0%, but the description supplies the key semantic the schema lacks: the slug is the lookup key for a single project card. That is meaningful, though it adds no format, casing, or validation detail beyond minLength.

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

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

States a specific verb (Read), resource (project card), and scope (one, public, by slug), which separates it from the sibling list_live_projects that returns many. It does not name a sibling explicitly, so it stops short of the top band.

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

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

The phrase 'by slug' implies you call this when you already have a single project identifier, but there is no explicit when-to-use, prerequisite, or pointer to alternatives such as list_live_projects for discovery.

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

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

No annotations are provided, so the description carries the behavioral burden. 'Read' and 'public' imply a safe, non-destructive, unauthenticated read, which is useful, but the description says nothing about return size, rate limits, caching, or whether the protocol is static.

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

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

A single short sentence with no waste and the key noun front-loaded after the verb. It is appropriately sized for a zero-parameter tool, though it borders on under-specification.

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

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

With no output schema and no annotations, the description is the only source of information, yet it does not say what the protocol returns or how an agent should use it. For a simple read tool this is adequate but leaves a real gap.

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

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

Zero parameters, so the baseline of 4 applies. There is no parameter surface for the description to explain, and the schema is trivially complete.

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

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

States a specific verb and resource: 'Read the canonical Humanity Loop public protocol.' An agent can tell this differs from sibling getters (get_action, get_project) by resource. However, it does not explain what the protocol content actually is or how it relates to the other Humanity Loop tools.

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

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

No when-to-use guidance, no mention of alternatives, and no indication of when an agent should fetch the protocol versus calling list_actions or get_project. The agent must infer the trigger entirely from the name.

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

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

There are no annotations to cover behavioral traits, so the description carries the full burden. It says the prompt is 'public,' which hints at accessibility, but does not disclose return format, whether the prompt is static or dynamic, or any other behavioral detail an agent would need.

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

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

The description is a single efficient sentence that front-loads the action and resource. It is appropriately sized for a no-parameter read tool, though it could be slightly more informative without becoming verbose.

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

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

Given the absence of annotations and output schema, the description should do more to explain what the tool returns and why it exists in the context of sibling tools. As written, it is too thin for an agent to confidently select or invoke it without additional inference.

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

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

The tool takes zero parameters, so there are no parameter semantics to explain; a baseline of 4 is appropriate given the 100% schema description coverage and no additional parameter meaning to add.

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

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

The description states a specific verb ('Read') and resource ('the public Humanity Loop replication prompt'), which is clearer than a tautology. However, it does not differentiate this tool from sibling read tools like get_protocol or get_project; the description could explain what a 'replication prompt' is or its relationship to those siblings.

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

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

No guidance is provided on when or why to use this tool versus alternatives. The description offers no context about use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at filtering ('recent', 'canonical') but never states ordering, default page size, whether it is read-only, or whether 'canonical' excludes anything—significant omissions for an unannotated tool.

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

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

One compact, front-loaded sentence with no wasted words. It is efficient, though the density of undefined domain terms slightly limits how much information the brevity actually conveys.

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

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

With no annotations, no output schema, and an undocumented parameter, the definition leaves the agent without defaults, ordering, or return-shape information. For a list tool the agent must know what 'recent' means in practice.

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

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

The single parameter 'limit' has 0% schema description coverage and is not mentioned anywhere in the description (no default, no max behavior, no effect on ordering). The description therefore fails to compensate for the coverage gap.

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

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

It states a specific verb (list) and resource (action-ledger entries), scoped to 'recent canonical' entries. This distinguishes it from the single-item sibling get_action, though the 'Humanity Loop' terminology is domain jargon an agent may not resolve.

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

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

There is no explicit guidance on when to choose this over get_action, list_live_projects, or search_dead_ends. Usage is only implied by the word 'list', with no prerequisites or exclusions stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It hints that results are 'public' and card-shaped, but says nothing about pagination, ordering, result limits, or whether any auth is required for a read-only listing.

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

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

A single front-loaded sentence with no filler, which is appropriate for a simple listing tool. It is arguably too terse rather than too long, but nothing is wasted.

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

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

With zero parameters and no output schema, the description is barely adequate: it does not describe what a returned 'card' contains or how many results to expect, which an agent would need when there is no output schema to fall back on. The low complexity of the tool keeps this at a minimum-viable level rather than a failure.

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

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

The tool takes zero parameters and the schema has 100% description coverage, so there is nothing for the description to clarify. Baseline for a no-parameter tool is 4.

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

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

States a specific verb (List) and resource (public Humanity Loop project cards), which reads as a read-only enumeration tool. It is distinguishable from the singular get_project sibling, though the description never names that contrast explicitly and 'cards' / 'live' vs 'public' wording leaves minor ambiguity about what is actually returned.

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

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

There is no when-to-use guidance, no mention of when to prefer get_project or list_actions, and no statement of prerequisites. An agent must infer entirely from the one-line purpose that this is the browse-all entry point.

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

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

With no annotations and no output schema, the description carries the full burden. It discloses only that the ledger is "public", which weakly implies no auth and read-only access, but says nothing about result shape, pagination, match semantics, or whether an empty query returns everything.

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

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

A single front-loaded sentence that wastes no words and identifies the target resource immediately. It is appropriately sized, though its brevity leaves the surrounding gaps unfilled.

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

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

For a tool with no annotations, no output schema, and an undocumented parameter, the description is too thin to let an agent call it correctly. It should at minimum clarify whether query is optional, what fields are searched, and how this relates to the sibling listing/get tools.

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

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

Schema description coverage is 0% and the single query parameter carries no type detail, format, or examples; the description adds no syntax or matching-behavior information either. Since required-parameter count is 0, it is also unclear what an omitted query does, which the one-sentence description never addresses.

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

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

States a specific verb ("Search") and a concrete resource ("Humanity Loop's public dead-end and rejected-path ledger"), so an agent knows it queries recorded failures and rejected approaches. It does not, however, distinguish itself from sibling list_/get_ tools like list_actions or get_project, so routing still requires inference from the verb alone.

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

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

There is no guidance on when to invoke this versus the ten sibling tools, and no mention of whether query is required or how results differ from list_actions. The agent must guess whether this is the canonical way to find abandoned approaches.

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