Companies where EVERY currently open role was posted in the last 30 days -- no backlog of applicants ahead of you, and usually a team that just started hiring. For sales, a company that just opened its first roles in a function is one whose budget has recently moved.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of explaining behavior. It clearly discloses the selection logic and the implications of the results. However, it doesn't mention whether results are sorted, paginated, or limited, nor does it state the output format or any implicit read-only guarantee.
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 two sentences and wastes little space. The core criterion is front-loaded, and the additional sales context earns its place by explaining why a 'fresh board' matters in a specific domain. It is compact and readable.
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 tool with one optional parameter and no output schema, the description gives a clear conceptual model of what is returned and why it is useful. However, it is incomplete on parameter meaning and does not describe the shape of results, ordering, or any limits. These gaps are significant but not fatal for a low-complexity 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?
The only parameter, limit, is an integer with no schema description, and the description does not mention it at all. Schema description coverage is 0%, so the description should compensate, but it doesn't. An agent can guess that limit caps the number of results, but the tool description provides no explicit semantics.
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 clearly identifies what the tool does: find companies where every currently open role was posted in the last 30 days. It gives a specific, testable criterion and implies a read-only list operation. It doesn't explicitly name sibling tools, but the 'fresh' vs 'quiet' contrast with find_quiet_boards gives implicit differentiation.
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 conveys when this tool is valuable: when you want no backlog of applicants and a team that just started hiring. The sales-specific sentence adds practical context for one use case. It does not explicitly state when not to use it or name alternatives, but the usage context is reasonably clear.
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 answers a clearly distinct question: company-specific verdict, fresh boards, quiet boards, market-level stats, job search, and change tracking. There is no meaningful overlap between tool purposes.
Four tools follow a verb-first pattern (check_company, find_fresh_boards, find_quiet_boards, search_jobs), but hiring_stats is a noun phrase and whats_changed is question-style. The names are readable but not fully predictable.
Six tools is well-scoped for a hiring intelligence server. Each tool covers a distinct aspect of the domain without redundancy or bloat.
The surface covers the core workflows: searching jobs, evaluating a single company, surfacing fresh versus quiet boards, viewing market stats, and monitoring changes. No obvious dead ends or missing critical operations for the stated purpose.