Talent Summoner

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

Adds real context beyond the annotations: the operation is asynchronous and returns emailLookupStatus, it calls an external enrichment provider, and results remain subject to the session's masking. It does not explain why destructiveHint=true is set — e.g. credit consumption or overwriting an existing email — which is the one behavioral fact an agent most needs before invoking.

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?

Three tight sentences, front-loaded with the action and immediately followed by what it returns and what happens next. No filler.

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?

Covers the async lifecycle, return value, provider dependency, and masking constraint — enough to invoke correctly without an output schema. Minor gaps remain around failure modes and cost/side-effect of the destructive hint.

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 coverage is 0%, so the description must carry the load. It implies the two parameters through 'one candidate in an owned sourcing session,' but gives no format, ownership prerequisite, or ID-source guidance for sessionId and candidateId.

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?

States a specific verb (start a work-email lookup) and resource (one candidate's work email) scoped to an owned sourcing session. It also implicitly separates itself from sourcing_read by making clear that tool is where the result surfaces, not where the lookup is triggered.

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?

Gives clear context: use this when you need to enrich a single candidate's work email, and the result will appear via sourcing_read later. It lacks explicit exclusions — e.g. whether to avoid calling when a lookup is already pending, or whether it can be re-run for the same candidate.

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?

Annotations only give generic destructive/non-idempotent/open-world flags; the description adds the substantive behaviour: the call is asynchronous, a running turn is replaced rather than queued, billing can halt a turn (billing.paymentRequired), and searches never consume paid Roles. These are exactly the side effects an agent needs before invoking a destructive tool.

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?

Front-loaded with the action and the return values, then constraints, then sibling routing — a sensible ordering with no filler. It is dense, and the final outreach sentence packs three tools into one line, but every clause conveys distinct operational 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?

With no output schema, the description still names the returned fields (sessionId, activity, appUrl) and explains that actual results land in sourcing_read, closing the loop an agent would otherwise be missing. Billing, role, and outreach edge cases are all covered.

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 coverage is 0% and neither parameter is documented in the schema, so the description carries the burden. It does convey meaning indirectly — 'owned sourcing session' scopes sessionId to a session the caller owns, and the examples clarify what userText should contain — but it never states that one call carries exactly one message, nor mentions the 10,000-character limit or the non-empty constraint.

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?

States a specific verb and resource ('Send one user message to an owned sourcing session') and immediately enumerates what such a message can be (ICP edit, approval, search request, refinement, outreach draft). It clearly separates this from sourcing_read (where results appear) and from the outreach siblings, so an agent can identify it without opening the schema.

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?

Provides concrete when-to-use examples, explains the post-call flow ('the work continues in the background and its results appear in sourcing_read'), warns about the replacement semantics of a second call, and explicitly routes to sourcing_unlock_role for Role assignment and to sourcing_outreach / sourcing_outreach_send for personalised outreach. Alternatives and exclusions are both named.

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?

The description adds substantial behavioral detail beyond the annotations, including pagination semantics, draftId/reviewFingerprint invalidation, paused-send status behavior, the 30-minute expiry window, and the fact that resolve may call the LinkedIn provider and update cached reachability. It does not elaborate the destructiveHint=true annotation or describe any irreversible effects, but it does disclose the key side effect of the resolve action and the simulated sandbox behavior.

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 front-loaded with the three action modes and then adds dense operational details, with essentially no filler. However, it is a long single paragraph covering multiple modes, so clearer structural separation of preview, status, and resolve would improve scanability.

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 complex seven-parameter tool with no output schema, the description is remarkably complete: it explains preview return fields and paging, status semantics and expiry, resolve side effects, error codes, and simulated sandbox behavior. An agent has enough information to select the right action and interpret the main results.

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 meaningfully compensates by explaining the three actions, the batchId returned by sourcing_outreach_send, and the paging role of recipientOffset/recipientLimit/bodyOffset. It does not explicitly define sessionId or channel, but channel is evident from the opening email/LinkedIn wording and sessionId is implied by 'owned session'.

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 opens with a specific multi-action purpose: previewing personalized outreach, reading batch status, or resolving LinkedIn reachability for an owned session. It names the resources and scope clearly and explicitly references sourcing_outreach_send, so an agent can distinguish the review tool from the sending tool.

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?

It gives concrete usage rules for status: batchId must come from sourcing_outreach_send, paused sends are indicated by pending above 0 with idle activity, and sending resumes via sourcing_outreach_send within the 30-minute confirmation window. It also explains preview invalidation after a changed draftId or reviewFingerprint, though it does not compare this tool against all sibling tools such as sourcing_review or sourcing_read.

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 annotations already marking the tool destructive and open-world, the description adds critical behavioral context beyond them: sending is irreversible, may contact external recipients, and can return simulated:true for sandbox accounts that delivered nothing. It also discloses the recovery window and expiry behavior, which directly affects how the agent should handle retries.

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 dense but front-loaded, starting with the action and its approval prerequisite before moving into first-confirmation requirements, recovery behavior, and return semantics. Every sentence provides operational value for a complex, irreversible action.

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?

There is no output schema, but the description still explains the meaningful return values: batchId, recipient count, and sending/resumed/replayed/confirmed_not_started status, plus the simulated flag. Given the tool's destructive, open-world nature and six parameters, the description covers the essential context an agent needs before invoking 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?

Schema description coverage is 0%, so the description has to carry parameter meaning, and it does: it explains sessionId, channel, draftId, reviewFingerprint, linkedinRiskAcknowledged, and batchId roles across the first-confirmation and recovery flows. It does not restate formats or types already present in the schema, but it compensates well for the lack of parameter descriptions.

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 uses a specific verb and resource: starting outreach sends through a connected email or LinkedIn account. It clearly distinguishes the first-confirmation path from the batchId recovery path, so the agent can tell exactly what operation this tool performs and when a different path applies.

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?

It states the prerequisite explicitly: the user must have reviewed every page of the preview and approved the exact sender, recipients, and messages. It also gives clear alternative usage: first confirmation requires sourcing_outreach-provided sessionId, channel, draftId, and reviewFingerprint, while recovery uses a confirmed batchId within 30 minutes before a 409 confirmation_expired failure.

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?

Although annotations already declare readOnly/idempotent/non-destructive, the description adds substantial non-obvious behavior: contacts masked until paid, billing.paymentRequired tri-state semantics (true/null/false), remainingFreshEvaluations, transcriptOffset counting back from newest, and the textLimits truncation condition with a concrete remedy. This is behavior an agent could not infer from schema or annotations.

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 purpose is front-loaded and most sentences carry unique information, but the body is a chain of semicolon-spliced fragments covering paging, filtering, billing and truncation with little visual grouping, making it dense to parse for a 12-parameter tool.

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?

No output schema exists, and the description compensates by naming the returned structures (session detail, open question, appUrl, candidates, transcript, candidatePage.missingCandidateIds, transcriptPage offset/limit/total/hasMore, billing fields). Combined with paging and truncation notes, an agent has what it needs to call and interpret this correctly.

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 carries the load, and it does explain candidateOffset/candidateLimit (max 50), transcriptOffset/transcriptLimit (max 20), candidateIds (max 50), selection, filterStatus, candidateSort and both view values. However, the top-level `limit` and `cursor` parameters — presumably the listing-mode pagination — are never mentioned, leaving a real gap.

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?

States a specific verb and resource ('Read owned session') and immediately clarifies the dual mode ('omit sessionId to list'), plus positions itself against the sibling sourcing_outreach for delivery status. An agent can identify this tool and its scope without opening the schema.

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?

Explicit routing is given: omit sessionId to list, use view "status" for a lightweight check, use sourcing_outreach for personalised messages and delivery status, and go to appUrl when the full ICP is needed. These are concrete when-to-use and when-to-use-something-else statements.

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?

Annotations declare destructiveHint=true and idempotentHint=true but can't express why; the description supplies exactly that by spelling out replace-previous-decision semantics, that omitted reasons/note preserve saved values, and that an empty list or string clears them. It also states the return ('the saved review'), which the tool has no output schema for.

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?

Three sentences, front-loaded with the action and decision values, then merge semantics, then ID provenance and return. No restatement of the name or title and no wasted clauses.

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?

Covers what an agent needs to call it correctly: mutation effects, partial-update behavior, ID source, and return value. It omits permission/ownership failure modes and the size limits on reasons/note, though the latter are in the schema.

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 carry the load, and it does for four of five params: candidateId provenance (from sourcing_read), selection values, and the omission-vs-empty semantics of reasons and note. sessionId is only implied by 'owned sourcing session' — nothing explains what a session id is or where to get one.

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?

States a specific verb and resource ('Save the user's review decision') and enumerates the decision domain (liked, shortlisted, skipped) scoped to one candidate in an owned sourcing session. That scope plus the pointer to sourcing_read makes it distinguishable from the sibling read/outreach tools without opening a schema.

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?

Gives the context that selects this tool (recording a decision on a candidate in a session you own) and routes ID acquisition to sourcing_read. It does not name an explicit alternative or a when-not condition, so it stops short of full routing guidance.

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?

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds real substance on top: the page is a snapshot frozen at publish time, update refreshes it from the current list, and 'update and revoke can end or replace previously published state.' It also discloses that the link is publicly viewable by anyone with the URL and that returns are bounded share metadata, never the full report snapshot.

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 core purpose is front-loaded in the first sentence and the rest is a dense but purposeful action breakdown with no filler. It is long and reads as one run-on block, which makes scanning the action list harder than it needs to be.

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 seven-action mutation tool with no output schema, it covers lifecycle, snapshot semantics, expiry options, return bounds, and reversibility of previously published state. The remaining gap is the previewFingerprint handshake between preview and create/replace, which an agent would have to infer.

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 coverage the description carries the full burden and mostly delivers: all seven action values are explained and expiryDays is documented as 1, 7, or 14 days. The previewFingerprint parameter is only alluded to as something preview produces, never stated as an input needed by create/replace, and sessionId is left uninterpreted.

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?

States a specific verb and resource: create and manage the single public link for a search, visible to anyone with the URL. That framing ('the one public link') distinguishes it cleanly from every other sourcing_* sibling, which deal with contacts, outreach, review, or reading results.

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?

Gives strong within-tool routing: status reads lifecycle, preview returns sanitized names plus fingerprint, create publishes, update republishes at the active URL, expiry/revoke/replace handle the end of life. It does not explicitly say when to pick this tool over siblings like sourcing_read or sourcing_review, so it falls short of a 5.

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?

Goes well beyond the annotations by disclosing the async contract: it returns sessionId/activity/appUrl as soon as the turn is accepted and the work continues in the background. It also discloses the billing behavior (searches never assign a paid Role, evaluation halts with billing.paymentRequired) — important context given destructiveHint=true and no output schema. It does not clarify that repeat calls create new sessions (idempotentHint=false).

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?

Front-loaded with the core action and the mode distinction, then the async/return contract, then the billing caveat. Dense but every clause carries information; the billing sentence is long and could be trimmed, but it prevents a costly misinterpretation.

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?

With no output schema, the description supplies the return shape (sessionId, activity, appUrl) and explains where the real results land (sourcing_read). Combined with the async and payment-required disclosures, an agent has everything needed to call this and interpret the immediate response.

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 carry parameter meaning. It fully explains startMode including which value is the default, but the required `prompt` parameter is only obliquely implied by "from a hiring brief" — no guidance on what the prompt should contain, its structure, or the 10000-character limit.

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?

States a specific verb and resource: "Create a sourcing session from a hiring brief and start its first turn." It then differentiates the two startMode behaviors and names the downstream siblings (sourcing_read, sourcing_unlock_role) so the agent knows exactly what this tool does versus what happens later.

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?

Explicitly explains which startMode to pick ("review_criteria" default drafts an ICP for review; "find_candidates" searches immediately), which is real routing guidance. It also directs the agent to sourcing_read for results and sourcing_unlock_role for Role assignment, though it never states when NOT to call this (e.g., when a session already exists and sourcing_continue should be used instead).

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?

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds meaningful behavioral context beyond that: it explains the cancelled true/false return semantics and explicitly states that candidates and results produced before the stop remain saved.

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 tight sentences, front-loaded with the core action and followed by return semantics and data-preservation behavior. Every sentence adds useful information without repetition.

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 one-parameter destructive tool with no output schema, the description covers the action, return semantics, and preservation of prior results. It does not address error cases or ownership validation, but it is otherwise complete enough to call correctly.

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% for the single required sessionId parameter, so the description must carry the semantic burden. It partially compensates by describing the target as an 'owned sourcing session' with an 'active turn,' but it does not name the parameter or explain its constraints explicitly.

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 uses a specific verb and resource: 'Cancel the active turn of an owned sourcing session.' That is clear and distinguishable from most siblings, but it does not explicitly contrast itself with sibling tools such as sourcing_continue or sourcing_start.

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?

Usage is implied by 'Cancel the active turn' and the 'owned sourcing session' qualifier, but the description gives no explicit when-to-use guidance, prerequisites, or named alternatives. An agent can infer the purpose, but routing versus sibling tools is left mostly to the tool name.

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?

Goes well beyond the annotations: the Role is spent and the action cannot be undone, already-paid sessions are unaffected, and specific HTTP-style failure codes are disclosed. These details are consistent with destructiveHint=true and idempotentHint=true, and add the cost/irreversibility context the annotations alone can't convey.

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?

Four tight sentences, front-loaded with the action and the spending/irreversibility constraint, then the idempotent edge case, then return value and errors. No filler.

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?

Despite no output schema, the description states what is returned (sessionId) and the failure conditions (402, 403). Combined with the behavioral constraints, an agent has everything needed to invoke it correctly and interpret the outcome.

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?

There is one required parameter at 0% schema description coverage. The description implies the sessionId must reference an 'owned sourcing session' and that sessionId is returned, but never explains the parameter itself. It partially compensates for the coverage gap but leaves the parameter's expected format unstated.

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?

States a specific verb and resource: assign a paid Role to a sourcing session to unlock paid access. The title and description together make clear this is a state-mutating unlock, distinct from the other sourcing_* siblings that contact, continue, read, or stop sessions.

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?

Explains the condition under which it applies and the no-op case ('a session that is already paid keeps its Role and no other is spent'), plus the failure conditions (402 no Role, 403 unverified email). It doesn't name a sibling alternative, but the action is unambiguous enough that no alternative is plausible.

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