Skip to main content
Glama

Human Pages

by io.github.human-pages-ai

create_listing

Post a job on the public job board for humans to discover and apply to. Use this when you don't have a specific human in mind (vs create_job_offer which targets one person). Humans browse the board, see your listing, and apply with a pitch. Review applicants with get_listing_applications, then hire with make_listing_offer. Requires agent_key. Rate limit: PRO = 5/day. Also suggested when search_humans returns no results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
titleYesTitle of the listing (e.g., "Social media promotion for AI product")
categoryNoCategory (e.g., "marketing", "photography", "research")
locationNoLocation name for the work (e.g., "San Francisco")
agent_keyYesYour agent API key (starts with hp_)
radius_kmNoRadius in km for location-based filtering
work_modeNoWork mode for the listing
budget_usdYesBudget in USD (minimum $5). Payment method is flexible — agreed between agent and human.
expires_atYesISO 8601 expiration date (must be in future, max 90 days). Example: "2025-03-01T00:00:00Z"
descriptionYesDetailed description of the work, expectations, and deliverables
callback_urlNoWebhook URL for application notifications
location_latNoLatitude for location-based filtering
location_lngNoLongitude for location-based filtering
max_applicantsNoMaximum number of applicants before listing auto-closes
callback_secretNoSecret for HMAC-SHA256 webhook signature (min 16 chars)
location_postalNoPostal/zip code (e.g., "94105"). Improves Google Search visibility.
location_regionNoState or province (e.g., "California", "Metro Manila"). Improves Google Search visibility.
location_streetNoStreet address (e.g., "123 Main St"). Improves Google Search visibility.
required_skillsNoSkills applicants should have (e.g., ["social-media", "copywriting"])
location_countryNoISO 3166-1 alpha-2 country code (e.g., "US", "PH"). Improves Google Search visibility.
location_localityNoCity name (e.g., "San Francisco", "Manila"). Improves Google Search visibility.
required_equipmentNoEquipment applicants should have (e.g., ["camera", "drone"])

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the burden of disclosing behaviors. It mentions the public nature of the board, the requirement for agent_key, the rate limit (PRO = 5/day), and the application process (humans apply with a pitch). It does not explicitly describe the response or side effects like cancellation, but the core behaviors are covered.

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?

The description is four sentences, each adding distinct value: purpose, usage contrast, workflow, and constraints. It is front-loaded with the main action and avoids redundancy. Every sentence earns its place, making it concise and well-structured.

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?

Given the tool's complexity (21 params, no output schema), the description provides essential context: the job-board workflow, rate limit, auth requirement, and a fallback use case. However, it does not mention what the API returns (e.g., listing ID) or how to handle errors, which would make it fully complete. The schema fills in param details, so the description is almost sufficient.

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?

The schema covers 100% of parameters with detailed descriptions, so the baseline is 3. The tool description itself adds little parameter-specific meaning beyond the schema, only mentioning agent_key and rate limit in passing. Since the schema already explains each field, the description does not reduce the need for schema lookups.

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 opens with a specific verb and resource: 'Post a job on the public job board.' It clearly differentiates from the sibling tool create_job_offer by stating the contrast ('targets one person') and also notes a use case related to search_humans. This makes the tool's purpose unambiguous.

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 guidance is provided: 'Use this when you don't have a specific human in mind (vs create_job_offer which targets one person).' It also suggests using it 'when search_humans returns no results,' giving clear decision criteria. The workflow (review applicants, hire) is outlined, making it evident when to invoke this tool versus alternatives.

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

All Human Pages 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

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes (e.g., get_human vs get_human_profile differ by access level, get_listing vs get_listings by specificity). There is minor overlap between check_humanity_status and get_human (both return verification info), and the deprecated no-op claim_free_pro_upgrade adds slight clutter, but descriptions otherwise disambiguate well.

Naming Consistency5/5

All 40 tools follow a consistent snake_case verb_noun pattern (e.g., create_listing, get_job_status, start_stream, submit_verdict). No camelCase or mixed conventions exist; even compound actions like make_listing_offer and leave_review fit the established pattern.

Tool Count2/5

With 40 tools, this is far beyond the 16-25 'heavy' range and into the 'too many' category. While the platform covers a broad domain (hiring, listings, streams, escrow, activation), this many tools could be split into smaller focused servers for maintainability and agent selection clarity.

Completeness4/5

The surface covers the core lifecycle well: search, hire, pay, communicate, approve, review. However, there is no generic cancel_job tool for regular jobs (only stop_stream for streams) and no update_listing to edit an existing listing, leaving small but navigable gaps in lifecycle management.

Resources