sourcers-desk

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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the burden of disclosing behavior. The phrasing 'About Sourcer's Desk' implies a read-only informational call, but it never explicitly states that no data is modified or that the tool simply returns static information. This is mildly unclear but not misleading.

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 a single, focused sentence that front-loads the tool's purpose with 'About Sourcer's Desk' and then concisely lists all meaningful topic areas. There is no extraneous content.

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, zero-argument informational tool, the description sufficiently covers what the tool provides. The presence of an output schema means return-value details are unnecessary, and the enumeration of topics is specific enough for an agent to decide when to call it.

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 has zero parameters and the schema description coverage is effectively 100%, so there is no parameter ambiguity. The description adds value by outlining the content areas an agent can expect, though it does not need to explain parameters since none 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?

The description clearly identifies the tool as an informational resource about Sourcer's Desk and enumerates the exact topics covered: playbook contents, API pricing, the Chrome extension, and AI agent payments. It is not a tautology and is likely to be understood as different from the generate_boolean_search sibling, though it does not use a strong action verb.

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 listed topics imply when an agent should use this tool: when a user asks about Sourcer's Desk, its pricing, the Chrome extension, or how AI agents pay. However, there is no explicit when/when-not guidance and no direct comparison to generate_boolean_search, so much is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.