Find Paid AI Work
find_paid_workFind the highest-ranked paid opportunity that passes AgentLot execution truth gates.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
find_paid_workFind the highest-ranked paid opportunity that passes AgentLot execution truth gates.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description usefully adds that it returns the single highest-ranked match rather than a list, and that results are filtered by 'truth gates' — but that filter criterion is left opaque, so the added context is only partial.
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 with the selection criterion ('highest-ranked') stated up front and no filler. It is efficient, though the closing clause is jargon-dense enough to cost a little readability.
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, the description should say what a returned 'opportunity' contains and whether credentials or prior setup (e.g. bountybook_authenticate, register_job_source) are required. It conveys only the selection rule, leaving the result shape and practical prerequisites for the agent to discover.
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 per the baseline there is nothing for the description to disambiguate. No param-level gaps exist.
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?
There is a concrete verb ('Find') and resource ('paid opportunity'), plus a scoping qualifier ('highest-ranked... that passes AgentLot execution truth gates'), so the intent is roughly graspable. However, 'AgentLot execution truth gates' is unexplained jargon and the sentence gives no hint of how this differs from siblings such as swarm_open_work, bountybook_live_job, or make_money_for_me.
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 never says when to use this versus the many adjacent money/work tools, nor any prerequisites, exclusions, or conditions. Usage can only be inferred from the word 'paid opportunity'.
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.