Search ToS-safe freelance job boards, rank leads by capability match and money heat, then push hot listings as Telegram cards with RU brief and EN pitch.
Hunt boards; push freelance-only HOT with RU brief + EN short pitch.
| Name | Required | Description | Default |
|---|---|---|---|
| min_heat | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. The verb "push" implies a write/side-effecting action (possibly outreach or queueing), yet the description does not state what is pushed, where, whether it is reversible, or what permissions are required. "Freelance-only" and the dual-language output are the only real behavioral disclosures.
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?
It is a single, front-loaded sentence with no filler, so it is structurally efficient. However, the density of unexplained abbreviations (HOT, RU, EN) trades clarity for brevity, which is a conciseness failure of a different kind. Adequate length, poor legibility.
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?
An output schema exists, so return values need not be explained, but for a pipeline-style tool with no annotations and an undocumented parameter the description is far from complete. It omits selection criteria, side effects, and how the "push" interacts with the sibling outreach tools. An agent could not invoke this correctly without guessing.
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 for the single parameter min_heat, and it does not mention it at all. Defaults and range for min_heat are left entirely to the raw schema. Only one parameter, but the description adds zero semantic value over the schema 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 phrase "Hunt boards" largely restates the tool name, and the second clause is a compressed jargon string ("HOT", "RU brief", "EN short pitch") whose meaning is not self-evident. Siblings like scan_for_leads, hot_leads, and chase_leads overlap heavily, and nothing here distinguishes hunt_jobs from them. An agent cannot confidently tell what this tool does that the siblings do not.
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 statement of when to use this tool, when not to, or which sibling to prefer for adjacent tasks (scanning, chasing, drafting). No prerequisites, cadence, or trigger conditions are given. The only hint is the word "freelance-only", which filters scope but not usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.