Online personal assistant for busy parents: home, kids, meals, admin and more
Scored across 2 tools
The two tools have clearly distinct purposes: one discovers task categories, the other submits a specific service request. There is no meaningful overlap that would cause an agent to select the wrong tool.
Both names use snake_case with a verb-first pattern: get_task_categories and request_sign_up_with_task. The convention is consistent and readable despite the longer second name.
Two tools is thin for a service surface, though the scope is narrowly defined around discovery and sign-up/request. It works but feels borderline minimal rather than well-scoped.
The core flow of browsing categories and submitting a task request is covered, but there is no way to check request status, retrieve submitted requests, or manage an account. These gaps limit follow-up workflows an agent might reasonably need.
Lists the kinds of everyday tasks Sherah's personal assistants handle for families in the US, as category and example-task pairs (for example Pets: Dog Walking, Kids: Camps, Home: Electrician), plus a link to Sherah's page about the tasks it helps with. The examples are a sample, not a complete list.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety bar is low. The description still adds real value beyond them by disclosing the response composition (pairs plus a link) and the important caveat that the examples are a sample, not a complete enumeration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that front-loads what is returned and backs it with examples, with the sample-not-exhaustive caveat placed at the end where it belongs. Slightly long but every clause (content, format, examples, link, caveat) carries information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A no-parameter, non-paginated informational read tool with no output schema — the description fully covers what comes back and flags the incompleteness caveat, which is the main risk. The only gap is not tying the output to the sign-up sibling, a minor omission for a listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool takes zero parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. No parameter text is needed or expected here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ("Lists") plus resource ("task categories") with the exact return shape spelled out as category/example-task pairs. The concrete examples (Pets: Dog Walking, Kids: Camps, Home: Electrician) make the content unambiguous, though it never names the sibling request_sign_up_with_task as the contrasting action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: an agent can infer this is a discovery step before signing up, but the description never says when to call it or that the category output feeds request_sign_up_with_task. No exclusions or alternative routing are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | The person's city. | |
| task | Yes | What the person needs done, in their own words (up to 2,000 characters). | |
| Yes | The person's own email address. The invitation is sent here. | ||
| state | Yes | The person's US state, as a two-letter USPS code (for example TX). | |
| needed_by | Yes | The date the person needs it done by, as YYYY-MM-DD, for example 2026-12-01. No time and no timezone. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_available_task_typesget_task_categoriesrequest_sign_uprequest_sign_up_with_task13 fields changedInput schema / additionalPropertiesRemoved value: -falseInput schema / properties / city / descriptionAdded value: +"The person's city."Input schema / properties / city / maxLengthRemoved value: -100Input schema / properties / city / minLengthRemoved value: -1Input schema / properties / email / descriptionAdded value: +"The person's own email address. The invitation is sent here."Input schema / properties / email / patternAdded value: +"^(?!\\.)(?!.*\\.\\.)([A-Za-z0-9_'+\\-\\.]*)[A-Za-z0-9_+-]@([A-Za-z0-9][A-Za-z0-9\\-]*\\.)+[A-Za-z]{2,}$"Input schema / properties / neededByRemoved 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"
-}Input schema / properties / needed_byAdded 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"
+}Input schema / properties / state / descriptionPrevious value: -"US state (two-letter code)"New value: +"The person's US state, as a two-letter USPS code (for example TX)."Input schema / properties / task / descriptionPrevious value: -"What do you need done?"New value: +"What the person needs done, in their own words (up to 2,000 characters)."Input schema / properties / task / maxLengthRemoved value: -2000Input schema / properties / task / minLengthRemoved value: -1Input schema / requiredPrevious value: -[
- "task",
- "neededBy",
- "email",
- "city",
- "state"
-]New value: +[
+ "task",
+ "needed_by",
+ "email",
+ "city",
+ "state"
+]get_available_task_typesrequest_sign_uprequest_sign_up_with_taskAI life manager: tasks, home, health, wealth, childcare, pets & more — on your own data.
Family calendars, tasks, reminders, and pickup coordination for your AI assistant.
Hand-picked gift ideas for new mums that assistants turn into shareable wishlists fast. SE + US.
AI-powered kitchen management — pantry, recipes, meal plans, shopping lists
Add one secure layer between your agents and this server.
