DogsLife turns a puppy's age and your day into a plan. Potty schedule (8 to 52 weeks): how long the puppy can usually hold it, how often to go out, whether to plan night trips, and a sample day with clock times. Sleep needs (8 weeks to 24 months): typical sleep per 24 hours, how much the night covers, and how many hours of naps are left. Same rules and sources (VCA, AKC, PetMD, Agria, Zoetis) as the calculators on dogslifeapp.com. Answers in 23 languages, with an interactive day-timeline card (MCP Apps). Read-only, no sign-in, nothing stored. Docs: https://dogslifeapp.com/connect.html
Scored across 2 tools
The two tools target clearly different concerns: house-training/potty frequency versus sleep and nap budgeting. Descriptions explicitly delimit scope (potty tool excludes adult-dog medical issues; sleep tool covers 8 weeks to 24 months), so an agent can pick correctly without guessing.
Both names follow the same predictable verb_noun pattern with a shared prefix: calculate_puppy_potty_schedule and calculate_puppy_sleep_needs. The convention is uniform and self-documenting.
Two tools is thin for a server branded as 'DogsLife' — it reads as a narrow calculator pair rather than a full puppy-care surface. Each tool does earn its place, but the set feels under-built for the apparent scope.
For a puppy-care guidance domain, obvious companion calculators are missing: feeding/portion amounts, exercise limits by age, crate-training duration, and vaccination or vet-visit timing. The two present tools are complete in themselves but leave agents at a dead end for adjacent common questions.
Makes a potty (toilet/house-training) schedule for a puppy aged 8 to 52 weeks: how long it can usually hold it, how often to take it out during the day, whether to plan night trips, and a sample day with clock times from wake-up to bedtime. For questions about how often to take a puppy out to pee, puppy potty or house-training schedules, and night-time potty trips. Age is in weeks (1 month is about 4.3 weeks). Gives general guidance based on vet and kennel-club sources (VCA, AKC, PetMD), not veterinary advice; not for adult dogs' medical problems such as accidents, diarrhoea or frequent urination.
| Name | Required | Description | Default |
|---|---|---|---|
| wake | No | When the household gets up, 24-hour HH:MM. Default 07:00. | 07:00 |
| bedtime | No | The puppy's bedtime, 24-hour HH:MM. Default 22:00. | 22:00 |
| language | No | The language the user is writing in, as a language code (e.g. en, de, sv, pt-BR, es-MX, ja, ar). The answer comes back in that language. | |
| age_weeks | Yes | The puppy's age in whole weeks, 8 to 52. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower; the description adds the substantive content of the response (hold time, day frequency, night trips, sample day with clock times) and discloses sourcing and a scope disclaimer. It does not specify exact output structure, but that is minor given the safety profile is covered.
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 and outputs are front-loaded in the first sentence, with usage cases and the scope disclaimer after. It is on the long side and the second sentence packs use cases, unit conversion, sourcing and exclusions together, but every clause 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?
With no output schema, the description does the work of describing what comes back (hold duration, daytime frequency, night-trip guidance, timed sample day) and sets expectations about sourcing and non-veterinary scope. An agent has enough to select and call it 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%, so baseline is 3, but the description adds real interpretive value beyond the schema: it clarifies that age is in weeks, notes that 1 month is about 4.3 weeks, and restates the 8–52 week bound. It says nothing extra about wake/bedtime/language, which the schema already documents well.
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 specific verb and resource ('Makes a potty schedule for a puppy aged 8 to 52 weeks') and enumerates the outputs (hold time, daytime frequency, night trips, sample day). It is plainly distinct from the sibling calculate_puppy_sleep_needs, which concerns sleep rather than house-training.
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?
Explicitly names the triggering questions ('how often to take a puppy out to pee, puppy potty or house-training schedules, and night-time potty trips') and gives a clear exclusion ('not for adult dogs' medical problems such as accidents, diarrhoea or frequent urination'). The only gap is that it doesn't name the sibling tool as the alternative for sleep questions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Works out how much a puppy or young dog (8 weeks to 24 months) typically sleeps per 24 hours, how much of that its night covers given the household's bedtime and wake-up time, how many hours of naps are left for the day, and the typical nap pattern for that age. For questions about how much a puppy should sleep, how many naps it needs, or whether a puppy sleeps too much or too little. Gives typical ranges from vet and kennel-club guidance (Agria, AKC, Zoetis), not veterinary advice; a sudden change in sleep or lethargy is a question for a vet.
| Name | Required | Description | Default |
|---|---|---|---|
| age | Yes | The puppy's age, in the unit below (8 weeks to 24 months). | |
| unit | No | Unit of age. | weeks |
| wake | No | When the household gets up, 24-hour HH:MM. Default 07:00. | 07:00 |
| bedtime | No | The puppy's bedtime, 24-hour HH:MM. Default 22:00. | 22:00 |
| language | No | The language the user is writing in, as a language code (e.g. en, de, sv, pt-BR, es-MX, ja, ar). The answer comes back in that language. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already carry readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered structurally. The description adds real context beyond that: provenance of the ranges (Agria, AKC, Zoetis), the explicit 'not veterinary advice' scope limit, and a clear statement of what the computation returns. It doesn't discuss precision or edge behavior at the 8-week/24-month boundaries, which keeps it at 4.
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?
Three sentences, front-loaded with the core computation before the usage triggers and the disclaimer. The first sentence is long but every clause maps to a distinct output, so it earns its length; minor trimming of the provenance list would make it tighter.
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?
There is no output schema, yet the description fully specifies the return shape (total 24-hour sleep, night coverage, remaining nap hours, nap pattern for the age). Combined with the vet disclaimer and the source of the ranges, an agent has everything needed to call this correctly and to frame the result appropriately.
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%, so the baseline is 3, but the description adds semantics the schema lacks: it explains that 'wake' and 'bedtime' define how much of total sleep the night covers and therefore how many nap hours remain, which tells the agent why those seemingly optional params matter. The stated 8–24 month applicability band also reinforces the age constraint.
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 specific verb-and-resource ('works out how much a puppy... typically sleeps per 24 hours') and enumerates the exact outputs: night coverage, remaining nap hours, and age-typical nap pattern. The subject matter is clearly disjoint from the only sibling, calculate_puppy_potty_schedule, so an agent can route without opening either schema.
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?
It gives explicit trigger questions ('how much a puppy should sleep, how many naps it needs, or whether a puppy sleeps too much or too little') and an explicit exclusion: sudden sleep change or lethargy is routed to a vet, not this tool. Both the when and the when-not are stated.
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.
calculate_puppy_potty_schedulecalculate_puppy_sleep_needsYour WHOOP data in the assistant, read-only: recovery, sleep, strain, workouts, cycles and body meas
Paw to paw. Shelter pets, one question away. Ask in plain words, in any of ten languages ("Use Petnecto to find me a calm older dog near Seattle that is good with cats") and get real adoptable pets near the place you name, with photos, ages, sizes, what each rescue says about them, and exactly how to reach the rescue. Listings come from open public data that shelters and governments publish (Taiwan's national adoption listings, King County WA and Montgomery County MD in the US, Zaragoza and Vienna in Europe), credited in every answer. Adoption always happens through the rescue: Petnecto takes no payments, applications or personal details, and needs no account.
Read pet activity and weight history, and log events with your permission.
Match dog breeds to your life, compare them, plan a test drive and estimate U.S. vet costs.
Add one secure layer between your agents and this server.
