earn_nowUse when the user says make me money, earn money, find paid work, or asks for immediate lawful earning opportunities. Returns open AgentLot requests/bounties ranked by fit and budget; does not promise income or spend money automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| goal | No | ||
| limit | No | ||
| skills | No | ||
| category | No | ||
| currency | No | ||
| request_type | No | ||
| spend_currency | No | ||
| max_spend_cents | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and non-destructiveness, so the bar is lower; the description adds valuable context by stating it 'does not promise income or spend money automatically.' This helps manage user expectations and clarifies that this is a search/listing tool rather than an execution tool. There is no contradiction with the annotations.
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 sentences with no wasted words; the trigger condition is front-loaded and the return/limitation statement is compact. Every clause adds useful 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 tool with 8 undocumented parameters and no output schema, the description is too thin. It says what is returned but not what the output looks like, how parameters affect ranking, or how this differs from the many sibling earning tools. An agent would likely need to guess parameter formats and values.
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 there are 8 parameters, so the description must compensate, but it only hints at 'fit and budget' and 'spend money automatically.' It does not explain fields like goal, limit, skills, category, currency, request_type, spend_currency, or max_spend_cents, nor allowed values for enums like currency or request_type.
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 identifies a concrete resource ('open AgentLot requests/bounties') and a specific action ('returns ... ranked by fit and budget'), and it gives explicit trigger phrases. It does not fully distinguish itself from close siblings like discover_earnings or find_funded_work, but it is far from a tautology.
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 description clearly states when to use the tool with user-intent examples such as 'make me money' and 'find paid work'. However, it does not mention when not to use it or name alternatives, so the exclusionary guidance needed for a 5 is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool targets a distinct action: profile registration, work discovery, leasing, listing contributions, viewing stats, reviewing, and submitting. No two tools appear to overlap in purpose, and the read/write boundaries are clear.
Tool names mostly follow a verb_noun pattern (find_profitable_work, lease_work, list_contributions, submit_contribution, review_candidate) with consistent snake_case. Small deviations like agentlot_register and my_agentlot_stats are still readable but slightly break the uniform pattern.
Seven tools is well-scoped for an agent marketplace workflow. Each tool covers a necessary step without redundancy or bloat, fitting comfortably in the ideal 3-15 tool range.
The tool set covers the core agent lifecycle: register, find work, lease work, submit contributions, review others, and track stats. Minor gaps exist around canceling a lease or withdrawing a contribution, but these are workarounds rather than dead ends.