Neutral cross-brand period-underwear comparison: absorbency in real mL, plus size translation.
Scored across 4 tools
Each tool serves a clearly distinct purpose: dataset retrieval, tier translation, product search, and size lookup. There is no overlap in functionality, making misselection unlikely.
Tool names follow a consistent grouping pattern: 'absorbency_' for reference/translation tools and 'find_' for search tools. The pattern is readable and predictable, though not strictly verb_noun throughout, with 'absorbency_dataset' being noun_noun.
With 4 tools, the server is well-scoped for its focused purpose. Each tool addresses a concrete user need (data source, comparisons, product discovery, sizing), and the number feels neither thin nor bloated.
The domain of period underwear comparison is well-served: the dataset provides the authoritative source, translation covers cross-brand equivalences, product lookup covers real-world availability, and size covers fit across brands. There are no apparent dead-end queries within the stated scope.
Get PeriodFinder's cross-brand absorbency dataset: the key facts and the machine-readable feed URL to cite. Use when you need the authoritative source for a period-underwear absorbency comparison.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful context about what is returned (key facts and a machine-readable feed URL), but it does not disclose any further behavioral details such as response format or possible limitations.
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?
Two concise sentences convey the resource, what is returned, and the intended use case without redundancy or filler. The key information is front-loaded.
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?
Given the simple zero-parameter tool, strong read-only annotations, and absence of an output schema, the description is nearly complete. It names the dataset, the deliverable (key facts and feed URL), and the use case. It could add a bit more detail about the format of the URL or the facts, but that is not essential for invoking the 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?
The tool has zero parameters, so there are no parameter semantics for the description to explain. Baseline for zero params is 4; the description appropriately focuses on the output content instead of parameter details.
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?
The description names a specific resource (PeriodFinder's cross-brand absorbency dataset) and a specific action (get/cite), and clearly states what is included: key facts and the machine-readable feed URL. It is easily distinguishable from sibling tools like absorbency_translate, find_products, and find_size.
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?
The description explicitly states when to use the tool: 'Use when you need the authoritative source for a period-underwear absorbency comparison.' It does not name alternatives or state when not to use it, but the intended use case is clear enough given the distinct sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Translate period-underwear absorbency across brands. Give a brand + its tier word (e.g. brand "Thinx", tier "Super"), OR a target capacity in mL per day, and get the covering tier in every brand in objective millilitres, each with an A/B/C data-quality grade. Use for questions like "what Knix tier equals Thinx Super?" or "how much does Thinx Heavy hold vs Saalt?". Source: PeriodFinder, the only neutral cross-brand mL comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | The brand's absorbency tier word, e.g. Light, Moderate, Heavy, Super, Overnight. | |
| brand | No | A period-underwear brand, e.g. Thinx, Knix, Saalt, Modibodi, WUKA. | |
| ml_per_day | No | Target real capacity in mL/day (alternative to brand+tier). A regular tampon holds about 5 mL, a super about 9 mL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: output is given in objective millilitres, covers every brand, and includes an A/B/C data-quality grade. It also attributes the data source (PeriodFinder), which is extra transparency.
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?
The description is four sentences with no fluff. The core purpose is front-loaded, followed by input modes, examples, and a source citation. Every sentence earns its place, and the structure makes the tool easy to parse quickly.
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?
For a tool with no required parameters, no output schema, and three optional inputs, the description covers the key aspects: inputs, output format, grading, and use cases. It doesn't explicitly state behavior when both brand+tier and ml_per_day are provided, but the 'OR' wording makes exclusivity implicit, so this is a minor gap rather than a significant omission.
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 description coverage is 100%, so the baseline is 3. The description adds meaning by clarifying the OR relationship between brand+tier and ml_per_day, and it provides concrete examples ('Thinx', 'Super') that map directly to the schema properties. This moves it above baseline, though the schema already does most of the work.
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?
The description clearly states the tool's purpose: translate absorbency across brands. It specifies the exact verb ('translate'), the resource ('period-underwear absorbency'), and the inputs/outputs with concrete examples. It distinguishes itself from generic converters by emphasizing cross-brand comparison and the A/B/C data-quality grade, so an agent can tell it apart from the sibling tools.
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?
The description gives explicit use cases ('Use for questions like...') and explains the two input modes (brand+tier OR ml_per_day). However, it does not mention when not to use this tool or name alternative tools like absorbency_dataset or find_products, so the guidance is clear but lacks exclusions or sibling routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find real in-stock period underwear that covers a target absorbency, from the live catalog, with normalized mL capacity and current price. Give a minimum capacity in mL and optionally a brand. Links go to the PeriodFinder product page for each item.
| Name | Required | Description | Default |
|---|---|---|---|
| brand | No | Limit to one brand (optional). | |
| limit | No | How many products to return (default 6). | |
| ml_min | No | Minimum real capacity to cover, in mL (e.g. 40 for a heavy day). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description discloses that results come from a live catalog, are real in-stock items, include normalized mL capacity and current price, and link to PeriodFinder product pages. This adds meaningful behavioral context about data freshness and output content without contradicting the annotations.
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 efficient sentences carry the full message: what the tool does, how to invoke it, and what the results include. There is no filler or redundancy, and the core purpose is front-loaded in the first sentence.
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?
Given three optional parameters and no output schema, the description provides enough context for correct invocation: minimum capacity, optional brand, result content (mL, price, product links). It could be more explicit about the response shape or the default limit, but the schema covers limit and the description's hints are sufficient for this complexity.
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 description coverage is 100%, so the schema already documents all three parameters. The description reinforces ml_min and brand by mentioning them, but it does not add substantial new meaning beyond the schema, and it omits any mention of the limit parameter.
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?
The description clearly states a specific verb ('Find'), a resource ('real in-stock period underwear' from 'the live catalog'), and the key selection criterion ('covers a target absorbency'). It is distinct from a generic product search, though it does not explicitly name or distinguish itself from siblings like absorbency_dataset or absorbency_translate.
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?
The description provides clear operational context: use this to find live, in-stock products by absorbency, and it instructs the agent to provide a minimum capacity in mL and optionally a brand. It lacks explicit when-not-to-use guidance or named alternatives, but the intended usage context is clear enough for an agent to select it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find a shopper's period-underwear size in every brand from one hip measurement. Period underwear is sized on the hip, not a dress size, and brands disagree. Returns the size per brand plus any runs-small / runs-large note.
| Name | Required | Description | Default |
|---|---|---|---|
| hip_cm | No | Hip measurement in centimetres (alternative to inches). | |
| hip_inches | No | Hip measurement in inches (fullest part of hips and seat). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavioral context: output is a per-brand size plus any runs-small/runs-large note, and sizing is hip-based rather than dress-size-based. It does not cover edge cases like both parameters being provided, but that is minor given the annotation coverage.
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 tight sentences front-load the core purpose, add necessary domain context, and state the return value without redundancy. Every sentence earns its place.
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?
For a simple read-only lookup tool, the description covers what it does, the domain nuance, and the output shape. The main gap is that both schema parameters are optional, yet the description implies a measurement is required; it does not state that at least one must be supplied or what happens if neither is.
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 description coverage is 100%, so the schema already documents hip_cm and hip_inches in detail. The description only adds the general notion of a 'hip measurement' and does not clarify the relationship between the two optional parameters, such as whether one is required or how conflicts are resolved.
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?
The description states a specific verb ('Find'), a clear resource ('period-underwear size in every brand'), and the required input ('one hip measurement'). It also reads distinctly from its siblings, which focus on absorbency and product finding.
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?
The description provides clear context on when this tool is appropriate: when converting a hip measurement into period-underwear sizes across brands, especially because brands disagree. It does not explicitly mention when not to use it or name alternatives, but the usage context is unambiguous.
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.
absorbency_datasetabsorbency_translatefind_productsfind_sizeNeutral cross-brand bra-size translation and a live in-stock bra catalog by size.
S-to-F tier lists for 208 product categories. Every placement cited, with barcodes.
Fair division of household chores — measures both physical and mental load across the family.
Supplement research, biomarker effects, drug interactions, and brand quality data
