StackFast FractWin Expert Brain

Talent Scout Record Relationship Activity

talent_scout_record_relationship_activity

Read-onlyIdempotent

Record one human-reported email, LinkedIn, SMS, call, or visit in the existing StackFast Relationship Core. Returns an immutable, idempotent receipt and makes follow-up state visible in Talent Scout. It never sends, scrapes, applies, submits, or changes candidacy status.

Input Schema

TableJSON Schema

Name	Required	Description
`channel`	Yes
`company`	Yes
`summary`	Yes	Factual summary of the already-completed human activity (maximum 5,000 characters; longer input is rejected and never silently truncated).
`direction`	Yes	Explicitly state whether the employer/contact initiated this activity, the candidate initiated it, or it is a system lifecycle event. No direction is inferred.
`tenant_id`	Yes
`occurred_at`	Yes	ISO-8601 timestamp for the human-completed activity.
`sqlite_path`	No	Optional local SQLite path for BYOC receipts; hosted cloud calls fail closed instead of reading local files.
`artifact_url`	No	Optional governed evidence URL; no artifact body is copied.
`contact_name`	Yes
`next_touch_at`	No	Optional ISO-8601 follow-up time.
`auth_token_key`	No	Optional wallet/env key name for the tenant Turso auth token. Never pass a raw token.
`idempotency_key`	Yes	Caller-stable key that makes retries return the original immutable receipt.
`database_url_key`	No	Optional wallet/env key name for the tenant Turso database URL. Never pass a raw URL or secret.
`tenant_database_type`	No	Optional physical database routing mode. Omit for the default internal StackFast DB; use sovereign_cloud only with wallet-resolved tenant DB credentials.
`related_queue_item_id`	No
`related_application_id`	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.

Changed3 schema fields changedAug 7, 2026

removedInput schema / properties / direction / default
```
Removed value: -"outbound"
```

changedInput schema / properties / direction / description

Previous value: -"Whether the employer/contact initiated this recorded activity, the candidate initiated it, or it is a system lifecycle event."New value: +"Explicitly state whether the employer/contact initiated this activity, the candidate initiated it, or it is a system lifecycle event. No direction is inferred."

changedInput schema / required

Previous value: -[
-  "tenant_id",
-  "idempotency_key",
-  "channel",
-  "company",
-  "contact_name",
-  "occurred_at",
-  "summary"
-]New value: +[
+  "tenant_id",
+  "idempotency_key",
+  "channel",
+  "direction",
+  "company",
+  "contact_name",
+  "occurred_at",
+  "summary"
+]

Changed2 schema fields changedAug 4, 2026

addedInput schema / properties / direction

Added value: +{
+  "default": "outbound",
+  "description": "Whether the employer/contact initiated this recorded activity, the candidate initiated it, or it is a system lifecycle event.",
+  "enum": [
+    "inbound",
+    "outbound",
+    "lifecycle"
+  ],
+  "type": "string"
+}

changedInput schema / properties / summary / description

Previous value: -"Concise factual summary of the already-completed human activity."New value: +"Factual summary of the already-completed human activity (maximum 5,000 characters; longer input is rejected and never silently truncated)."

Changed1 schema field changedAug 4, 2026

changedInput schema / properties / channel / enum

Previous value: -[
-  "email",
-  "linkedin",
-  "call",
-  "visit"
-]New value: +[
+  "email",
+  "linkedin",
+  "sms",
+  "call",
+  "visit"
+]

AddedJul 24, 2026

TDQS

A3.5/5.0

Behavior1/5

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

The description claims the tool records activity into the Relationship Core and makes follow-up state visible, both implying state change, while annotations declare readOnlyHint=true. This is a direct annotation contradiction and leaves agents with conflicting side-effect expectations.

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

Conciseness5/5

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

Three sentences: action/resource first, result second, exclusions third. Every sentence carries distinct value with no repetition of schema structure or annotation fields.

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

Completeness3/5

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

For a 16-parameter tool, it communicates the core action, result, and boundary conditions, and an output schema exists to explain the receipt shape. However, it does not clarify prerequisites for the 'existing Relationship Core' nor route to the correction sibling, and the readOnly contradiction undermines complete operational clarity.

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?

The description adds no parameter-level semantics beyond the schema; phrases like 'human-reported' and 'already-completed' mirror the summary parameter's schema description. With 63% schema coverage, the schema does most of the work, and uncovered fields like related_queue_item_id and related_application_id remain unaddressed but are largely self-descriptive.

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?

Opens with a specific verb and resource: recording human-reported email/LinkedIn/SMS/call/visit into the existing StackFast Relationship Core. The negative list (never sends, scrapes, applies, submits, or changes candidacy status) further separates it from sender/application pipeline siblings.

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?

Clearly scopes usage to already-completed, human-reported activities and explicitly lists actions it never performs, which prevents sending/application misuse. It does not name an alternative like talent_scout_correct_relationship_activity for amendments, so it is just 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.

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?