Generate recruiter-grade boolean search strings for a role: LinkedIn x-ray + open-web resume search, with expanded titles and practitioner skill terms from a 20-year sourcing playbook. Takes 1-3 minutes. role_description is required; location is a city/metro.
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | both | |
| location | No | ||
| constraints | No | ||
| role_description | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It usefully conveys what the tool produces (LinkedIn and open-web strings, expanded titles, pragmatic skill terms) and the expected 1-3 minute runtime. It doesn't mention side effects, but this is a non-destructive content-generation tool where that is less critical.
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 three concise sentences with no filler. It is densely informative, putting the main purpose first, then the key scope details, then critical input requirements with timing noted. Every sentence carries 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?
Given all the optional parameters and empty schema descriptions, the description provides important context for role_description, location, timing, and what the output will contain. However it does not explain target or constraints, which are noticeable gaps for an agent trying to call the tool correctly the first time.
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?
With 0% schema description coverage, the description must compensate for the parameter semantics. It details role_description as required and location's city/metro format, but says nothing about what 'target' or 'constraints' mean. These are left ambiguous, so the description does not sufficiently substitute for the missing schema descriptions on half the parameters.
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 states the verb 'generate', the resource ('recruiter-grade boolean search strings'), and the exact scope (LinkedIn x-ray plus open-web resume search with expanded titles and skills). It provides enough detail that the agent can distinguish it from the sibling tool sourcers_desk_info, which appears informational by comparison.
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 gives clear usage context: the role_description input is required, location should be a city/metro, and runtime is 1-3 minutes. It does not explicitly discuss when to use this tool over alternatives or state when not to use it, so it misses the full 'when-not' guidance, but the built-in context is strong.
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.
The two tools have entirely separate purposes: one generates boolean search strings, the other provides server information. There is no overlap or potential for confusion between them.
Both names are descriptive and follow a readable pattern. 'generate_boolean_search' uses verb_noun and 'sourcers_desk_info' is a noun phrase. The slight inconsistency in convention is minor but noticeable.
With only one functional tool plus an info tool, the server feels thin. However, the narrow purpose of generating boolean searches limits the necessary surface, so the count is borderline rather than ideal.
For the stated purpose, the server provides its core functionality and a way to learn about the service. It lacks additional helper tools (e.g., validating or refining searches), but those may be beyond the intended scope.