Skip to main content
Glama

recommendation_request_email

Craft a short email asking a satisfied client for a LinkedIn recommendation. Includes memory prompts and optional focus suggestions to make writing easy.

Instructions

Write the email asking a happy client for a LinkedIn recommendation. Different from testimonial_request (which asks for a short quote for your website): a LinkedIn recommendation lives on the client's own profile and carries far more social proof. This email makes the ask easy — keeps it short, gives the client a memory prompt, and optionally suggests a focus so they don't face a blank page. Does not count against your monthly draft limit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
client_nameYesThe client's first name
project_nameYesThe project or engagement to reference (e.g. 'the brand identity project', 'the six-month content retainer', 'the website redesign')
standout_resultNoOptional: a specific result or moment to remind them of — gives them something concrete to write about (e.g. 'the site launched on time and traffic doubled in the first month', 'the proposal we worked on won the Deloitte contract')
focus_suggestionNoOptional: what aspect of the work you'd love them to speak to — makes it easier for them to write (e.g. 'communication and turnaround speed', 'the strategic thinking behind the copy', 'reliability and quality under a tight deadline'). Keep to one thing.
your_nameNoOptional: your name for the sign-off
Behavior4/5

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

No annotations are provided, so the description bears the full burden. It discloses that the email does not count against a monthly draft limit and describes its strategy (keeps it short, gives memory prompt, optional focus). It implies a non-destructive write operation, but lacks explicit statements about reversibility or permissions. Still, it is fairly transparent.

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?

The description is a single paragraph that front-loads the core purpose and differentiation. Every sentence adds value: purpose, distinction from sibling, strategy for the email, and a key constraint (draft limit). No redundant words.

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

Completeness5/5

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

Given no output schema, the description does not need to explain return values. It covers the email's purpose, usage scenarios, parameter guidance, and behavioral characteristics (no draft limit). For a simple email generation tool, this is complete.

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

Parameters4/5

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

Schema coverage is 100% (all parameters have descriptions), so baseline is 3. The description adds extra meaning beyond the schema by explaining the strategic purpose of optional parameters: 'standout_result' is a memory prompt, 'focus_suggestion' makes writing easier, 'your_name' is for sign-off. This adds value.

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 clearly states the tool's purpose: 'Write the email asking a happy client for a LinkedIn recommendation.' It uses a specific verb 'Write' and resource 'email,' and distinguishes itself from the sibling tool 'testimonial_request' by explaining the difference between a LinkedIn recommendation and a testimonial quote.

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

Usage Guidelines5/5

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

The description explicitly differentiates this tool from 'testimonial_request' and explains when to use each. It also provides context on how to use the optional fields to make the ask easy, including a memory prompt and focus suggestion. This gives clear guidance on usage.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/jabbawocky/proposalcraft'

If you have feedback or need assistance with the MCP directory API, please join our Discord server