HireSquire Agent Ecosystem

generate_email

Generate a personalized outreach or follow-up email for a specific candidate. Use this after identifying a strong candidate from "get_results" to move them through the pipeline.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "job_id": "<job_id>",
      "candidate_id": "<candidate_id>",
      "type": "<type>"
    },
    "name": "generate_email"
  }
}

Input Schema

Name	Required	Description	Default
`tone`	No	The desired tone of the generated email.	professional
`type`	Yes	Type of email: "invite" for interviews, "rejection" for non-matches, etc.
`job_id`	Yes	The job ID.
`candidate_id`	Yes	The specific candidate ID from the results.
`custom_message`	No	Additional context or instructions to include in the AI-generated email.

Output Schema

Name	Required	Description	Default
`body`	No
`subject`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedMay 16, 2026

changedInput schema / properties / candidate_id / description

Previous value: -"The candidate ID."New value: +"The specific candidate ID from the results."

removedInput schema / properties / candidate_id / examples
```
Removed value: -[
-  456
-]
```

changedInput schema / properties / custom_message / description

Previous value: -"Optional custom message"New value: +"Additional context or instructions to include in the AI-generated email."

removedInput schema / properties / job_id / examples
```
Removed value: -[
-  123
-]
```

addedInput schema / properties / tone

Added value: +{
+  "default": "professional",
+  "description": "The desired tone of the generated email.",
+  "enum": [
+    "professional",
+    "friendly",
+    "formal"
+  ],
+  "type": "string"
+}

removedInput schema / properties / type / default
```
Removed value: -"invite"
```

changedInput schema / properties / type / description

Previous value: -"Type of email to generate."New value: +"Type of email: \"invite\" for interviews, \"rejection\" for non-matches, etc."

First observedMay 11, 2026

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are supplied, so the description carries the full burden. It never states whether the generated email is merely drafted or actually sent to the candidate, whether it consumes credits (relevant given sibling credit tools), or whether generation is reversible or previewable — critical ambiguities for an agent operating on real candidates.

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?

Two sentences, front-loaded with the action and followed by the triggering condition; no filler or redundancy.

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?

An output schema exists, so return values need not be explained. However, for a tool with no annotations that acts on a real candidate, the description omits the send-vs-draft distinction and any cost or permission context, leaving meaningful gaps.

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 coverage is 100%, with both enums documented, so the schema already explains tone, type, job_id, candidate_id, and custom_message. The description adds no parameter-specific meaning beyond the schema, which is the expected baseline here.

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

Purpose4/5

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

The description gives a specific verb+resource ("Generate a personalized outreach or follow-up email") and scopes it to a single candidate, which implicitly separates it from the bulk sibling. It stops short of explicitly naming bulk_generate_emails as the alternative for multi-candidate work.

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 states a clear precondition and predecessor: use after identifying a strong candidate from get_results. It does not state when to avoid this tool (e.g., bulk workflows, candidates already contacted), so the guidance is contextual but not exhaustive.

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

All HireSquire Agent Ecosystem 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?