Skip to main content
Glama

YouSpot

by com.youspot
OverviewDiscussionsAdmin

Update email notifications

set_notification_emails

Turn the recurring emails YouSpot itself sends the user off or back on, when they ask to stop getting one, unsubscribe, or resume it. The emails: exec_briefings is the daily 'Exec Briefing' built from their Second Brain; post_reports is the 'Your posts' section of that briefing (a LinkedIn post that is new or gaining traction); process_emails are the one-off notices when an import or sync finishes; agent_emails is the mail their cloud agents and LinkedIn or X watchers send (the agents keep running, only the email stops); tracker_updates is the email when a web page tracker finds a change. Pass only the settings they mean, false to stop. When they say 'this email' or 'the one I just got' without naming it, call with no arguments first: the result names the last email YouSpot sent them and the setting behind it, then call again with that setting false. This is for YouSpot's own mail only; for newsletters or senders in their Gmail use the Gmail tools. Confirm in plain words what is now off (or on) and that they can change it any time at the settings_url returned.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
agent_emailsNoEmail from their cloud agents and watchers. false stops the email, not the agents.
post_reportsNoThe 'Your posts' traction section of the Exec Briefing. false leaves it out.
exec_briefingsNoThe daily 'Exec Briefing' email. false stops it.
process_emailsNoThe notices when an import or sync finishes. false stops them.
tracker_updatesNoThe email when a web page tracker finds a change. false stops it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / agent_emails
      Added value: +{
+  "description": "Email from their cloud agents and watchers. false stops the email, not the agents.",
+  "type": "boolean"
+}
    • addedInput schema / properties / tracker_updates
      Added value: +{
+  "description": "The email when a web page tracker finds a change. false stops it.",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / post_reports / description
      Previous value: -"The recurring 'Insights from your LinkedIn posts' report. false stops it."New value: +"The 'Your posts' traction section of the Exec Briefing. false leaves it out."
  3. Added

TDQS

A4.6/5.0
Behavior4/5

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

Annotations only provide readOnlyHint=false, so the description carries the burden of behavioral disclosure. It reveals that agent_emails stops only the email, not the agents; clarifies that false is the actionable value; and discloses the tool's behavior when called with no arguments (returns the last email and the setting behind it). It does not mention permissions or rate limits, but for this low-risk toggle that's a minor gap.

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 long, but every sentence earns its place: purpose, email-type enumeration, the no-arguments special case, the Gmail exclusion, and the confirmation instruction are all necessary for correct use. It is well-organized despite being a wall of text, and the length is justified by the tool's complexity.

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?

The tool has 5 optional parameters and no output schema, so the description's partial return information (the no-args case naming the last email and the returned settings_url) is valuable. It covers the main ambiguity and exclusion. The general return shape for a normal toggle call is not fully specified, but an agent can still act correctly given the instructions.

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

Parameters5/5

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

Schema coverage is 100%, yet the description adds substantial meaning beyond the schema: it maps each boolean to its human-readable email type (e.g., exec_briefings is the daily 'Exec Briefing' from their Second Brain), explains the relationship between post_reports and exec_briefings, and clarifies the semantic of false for each setting. This is far more than the schema's one-line descriptions.

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 states a specific verb ('turn off or back on') with a precise resource (the recurring emails YouSpot sends the user), enumerates all five email types with plain-language explanations, and explicitly distinguishes itself from Gmail tools. An agent can immediately tell this tool from siblings like send_email or archive_gmail_message.

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?

It gives explicit triggers ('when they ask to stop getting one, unsubscribe, or resume it'), names the alternative tool category for non-YouSpot mail ('for newsletters or senders in their Gmail use the Gmail tools'), and provides a concrete two-step procedure for ambiguous requests. This leaves no doubt about when and how to invoke the tool.

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

All YouSpot toolsInspect
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