Skip to main content
Glama
Sign In

Sherah

by com.mysherah
OverviewDiscussionsAdmin

Request Sign-Up With a Task

request_sign_up_with_task

Submits a request for Sherah's help with one task, on behalf of a person in the US and with details that person provides: the task in their own words, the date they need it done by, their email address, city and two-letter US state. Sherah is a personal-assistant service for families. If the email address is new to Sherah, Sherah emails the person an invitation to create an account, and the task is waiting for them after sign-up. Returns whether the request was submitted and a message for the person.

Input Schema

NameRequiredDescriptionDefault
cityYesThe person's city.
taskYesWhat the person needs done, in their own words (up to 2,000 characters).
emailYesThe person's own email address. The invitation is sent here.
stateYesThe person's US state, as a two-letter USPS code (for example TX).
needed_byYesThe date the person needs it done by, as YYYY-MM-DD, for example 2026-12-01. No time and no timezone.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed13 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / city / description
      Added value: +"The person's city."
    • removedInput schema / properties / city / maxLength
      Removed value: -100
    • removedInput schema / properties / city / minLength
      Removed value: -1
    • addedInput schema / properties / email / description
      Added value: +"The person's own email address. The invitation is sent here."
    • addedInput schema / properties / email / pattern
      Added value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"
    • removedInput schema / properties / neededBy
      Removed value: -{
-  "description": "When do you need it done by? A calendar date as YYYY-MM-DD, e.g. 2026-08-01. Resolve relative dates like 'next Tuesday' yourself before calling. No time and no timezone.",
-  "format": "date",
-  "type": "string"
-}
    • addedInput schema / properties / needed_by
      Added value: +{
+  "description": "The date the person needs it done by, as YYYY-MM-DD, for example 2026-12-01. No time and no timezone.",
+  "type": "string"
+}
    • changedInput schema / properties / state / description
      Previous value: -"US state (two-letter code)"New value: +"The person's US state, as a two-letter USPS code (for example TX)."
    • changedInput schema / properties / task / description
      Previous value: -"What do you need done?"New value: +"What the person needs done, in their own words (up to 2,000 characters)."
    • removedInput schema / properties / task / maxLength
      Removed value: -2000
    • removedInput schema / properties / task / minLength
      Removed value: -1
    • changedInput schema / required
      Previous value: -[
-  "task",
-  "neededBy",
-  "email",
-  "city",
-  "state"
-]New value: +[
+  "task",
+  "needed_by",
+  "email",
+  "city",
+  "state"
+]
  2. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Adds real behavior beyond the annotations: an invitation email is sent when the address is new to Sherah, the task waits for the person after sign-up, and the response reports submission status plus a person-facing message. The openWorld and non-idempotent hints are declared, but the description does not address duplicate submissions or failure modes for an existing account.

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?

Purpose is front-loaded in the first clause, followed by constraints and side effects, with no filler. The one-line explanation of Sherah's service is short and earns its place by grounding the request.

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?

No output schema exists, and the description still says what comes back (submitted flag and a message for the person). Required data, geographic restriction, and the new-vs-existing email branch are all covered, which is everything needed to call a 5-parameter required-field tool correctly.

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 descriptions and an enum for state, so the schema already carries parameter meaning. The description reinforces that all values come from the person themselves and that the email is the invitation destination, but adds no format or edge-case detail beyond that.

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?

States a concrete verb and resource ('Submits a request for Sherah's help with one task') plus the scope (one task, on behalf of a US-based person, with that person's own details). The sibling get_task_categories is an unrelated category read, so there is no ambiguity to resolve.

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?

Implicit eligibility conditions are stated clearly: one task per request, person must be in the US, details must come from that person. There is no explicit when-not guidance or named alternative, but the only sibling is an unrelated read tool, so the practical gap is small.

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

All Sherah 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