StackFast FractWin Expert Brain

Talent Scout Application Workup

talent_scout_application_workup

Read-onlyIdempotent

Build the detailed workup for one Talent Scout queue item: availability status, fit risks, company pain map, Robert proof-point map, resume angle, application strategy, and a full draft-only application packet with resume edits, cover-letter outline, form-paste answer, compensation guidance, LinkedIn/follow-up drafts, founder-objection answers, first-30-days plan, questions to ask, claims/risk validation, manual submission receipt template, interview prep, and learning-loop signals. Draft/review only; no sends or applications.

Input Schema

TableJSON Schema

Name	Required	Description
`notes`	No
`title`	No	Role title lookup when queue_item_id is not known.
`company`	No	Company name lookup when queue_item_id is not known.
`tenant_id`	No
`queue_item_id`	No	Preferred exact Talent Scout queue item id. If omitted, provide company and title.
`application_id`	No	Optional ATS/portal application or requisition id, such as R110984. Resolves only to an existing Talent Scout queue/history record.
`requisition_id`	No	Alias for application_id when the id is a req/requisition id.
`canonical_job_id`	No	Optional canonical job id lookup. Resolves only to an existing Talent Scout queue/history record.
`job_description_text`	No	Optional full JD pasted by the owner when the stored role is thin or JavaScript-rendered. It hydrates this draft-only workup without returning the raw JD.
`portal_application_id`	No	Alias for application_id when the id came from an external portal.
`user_supplied_jd_text`	No	Alias for job_description_text. Used as owner-supplied JD evidence only for this governed workup.
`include_follow_up_plan`	No
`include_interview_prep`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	No
`public_tool`	Yes
`drafts_never_sends`	No
`no_autonomous_outbound`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedAug 4, 2026

addedInput schema / properties / job_description_text

Added value: +{
+  "description": "Optional full JD pasted by the owner when the stored role is thin or JavaScript-rendered. It hydrates this draft-only workup without returning the raw JD.",
+  "type": "string"
+}

addedInput schema / properties / user_supplied_jd_text

Added value: +{
+  "description": "Alias for job_description_text. Used as owner-supplied JD evidence only for this governed workup.",
+  "type": "string"
+}

Changed1 schema field changedJul 8, 2026

changedInput schema / properties / portal_application_id / description

Previous value: -"Alias for application_id when the id came from a candidate portal."New value: +"Alias for application_id when the id came from an external portal."

Changed4 schema fields changedJul 8, 2026

addedInput schema / properties / application_id

Added value: +{
+  "description": "Optional ATS/portal application or requisition id, such as R110984. Resolves only to an existing Talent Scout queue/history record.",
+  "type": "string"
+}

addedInput schema / properties / canonical_job_id

Added value: +{
+  "description": "Optional canonical job id lookup. Resolves only to an existing Talent Scout queue/history record.",
+  "type": "string"
+}

addedInput schema / properties / portal_application_id

Added value: +{
+  "description": "Alias for application_id when the id came from a candidate portal.",
+  "type": "string"
+}

addedInput schema / properties / requisition_id

Added value: +{
+  "description": "Alias for application_id when the id is a req/requisition id.",
+  "type": "string"
+}

Changed4 schema fields changedJun 19, 2026

addedInput schema / properties / company

Added value: +{
+  "description": "Company name lookup when queue_item_id is not known.",
+  "type": "string"
+}

addedInput schema / properties / queue_item_id / description

Added value: +"Preferred exact Talent Scout queue item id. If omitted, provide company and title."

addedInput schema / properties / title

Added value: +{
+  "description": "Role title lookup when queue_item_id is not known.",
+  "type": "string"
+}

removedInput schema / required
```
Removed value: -[
-  "queue_item_id"
-]
```

AddedJun 16, 2026

TDQS

A4.3/5.0

Behavior5/5

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

Annotations already mark this as readOnly, idempotent, and non-destructive, and the description adds meaningful behavioral context by calling it a draft-only application packet and explicitly stating no sends or applications. This tells an agent exactly what side effects are avoided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is dense and front-loaded, but it is one long comma-delimited list. The list is informative for a complex tool and each item largely earns its place, though grouping or bullet formatting would improve scannability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex tool with an output scheema and rich annotations, the description covers the full scope of the workup and clearly limits side effects. Minor gaps remain around unexplained terms like 'Robert proof-point map' and how to select between lookup parameters, but the core behavior and expected outputs are complete enough.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 69% and the schema already documents aliases and fallback behavior for the lookup parameters. The description adds no parameter-level guidance and instead focuses on outputs, which is acceptable but not compensating beyond the schema's existing coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: Build the detailed workup for one Talent Scout queue item. It then enumerates concrete deliverables, making the tool's purpose unmistakable and distinct from sibling send/action tools by stating Draft/review only; no sends or applications.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It clearly identifies the target context: one Talent Scout queue item, and the boundary: draft/review only with no sends or applications. However, it does not explicitly name an alternative tool for the send path or exclusions beyond that, so it stops short of fully explicit routing.

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

All StackFast FractWin Expert Brain tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?