Skip to main content
Glama
ruchitha-meenakshi

HR-ASSIST

by ruchitha-meenakshi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

send_email

Sends an email to one or more recipients with a subject and body, enabling HR teams to automate notifications, onboarding, and scheduling communications.

Instructions

Send an email to one or more recipients.
:param to_emails: List of email addresses
:param subject: Email subject
:param body: Email body content
:return: Success message

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYes
htmlNo
subjectYes
to_emailsYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. Beyond the fact that this sends an email, it discloses nothing about authentication requirements, rate limits, whether the send is irreversible, or what the success/failure response looks like.

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

Conciseness3/5

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

The prose sentence is appropriately brief and front-loaded. The subsequent :param/:return lines are boilerplate docstring fragments that add little value, pulling the structure down from efficient to merely adequate.

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

Completeness2/5

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

Given 4 parameters at 0% schema coverage and no annotations, the description is too thin. It omits the undocumented 'html' parameter entirely and provides no behavioral context; the output schema partly offsets this by covering return values, but the core gaps remain.

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

Parameters2/5

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

Schema description coverage is 0%, so the schema does not document any of the 4 parameters. The description names three parameters but adds no meaning beyond their names and gives no explanation for the undocumented 'html' parameter, leaving a clear gap it should have filled.

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?

States a specific verb+resource ('Send an email') that is distinct from siblings like schedule_meeting or create_ticket. The audience ('one or more recipients') adds a scoping detail. It lacks explicit sibling differentiation, which is minor given no sibling also sends email.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives. The description gives no context about prerequisites such as whether the recipient must be a known employee or how it relates to other communication tools.

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

Deploy Server

Other Tools