About Sourcer's Desk: what the playbook encodes, pricing of the pay-per-call API, the Chrome extension, and how AI agents pay.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
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.
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.