Neutral cross-brand period-underwear comparison: absorbency in real mL, plus size translation.
Scored across 4 tools
Each tool targets a distinct job: citing the dataset, translating absorbency tiers, finding products, and finding sizes. There is no meaningful overlap, and the descriptions make the boundaries clear.
find_products and find_size follow a clean verb_noun pattern, but absorbency_dataset and absorbency_translate invert the convention (noun_noun and noun_verb). All names are readable and snake_case, so the inconsistency is moderate rather than chaotic.
Four tools are well-scoped for a narrow comparison and shopping domain. Each tool covers a distinct user need without redundancy or bloat.
The surface covers the full consumer journey: authoritative absorbency reference, cross-brand translation, live product search, and size conversion. No obvious dead ends or missing core operations for the stated purpose.
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. Teen and tween lines are left out unless teen is true.
| Name | Required | Description | Default |
|---|---|---|---|
| teen | No | Include teen / tween lines (default false: adult lines only). | |
| 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?
Annotations already declare this read-only/idempotent/non-destructive, and the description adds meaningful behavior beyond that: the results are 'real in-stock' from a 'live catalog', capacities are normalized, prices are current, links go to a product page, and teen lines are filtered unless requested. This is rich, accurate behavioral disclosure.
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 compact and front-loaded, with every sentence adding value: what is searched, what inputs are expected, and what results contain. No filler or redundant elaboration.
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 read-only search tool with four optional parameters fully documented in the schema, the description is sufficient. It explains the live data source, return expectations (mL capacity, price, product links), and teen filtering. There is no output schema, but the description covers the key output characteristics an agent would need.
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 schema already documents all four parameters well. The description restates ml_min and brand and clarifies the teen default behavior, but it does not add substantial new meaning beyond the schema descriptions.
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 uses a specific verb ('Find') with a specific resource ('real in-stock period underwear') and a clear selection criterion ('target absorbency'). It also states it draws from the live catalog and returns normalized mL capacity and current price, which clearly distinguishes it from siblings like absorbency_dataset, absorbency_translate, 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 gives clear operational context: the caller provides a minimum mL capacity and optionally a brand, and teen/tween lines are excluded unless teen is true. It does not explicitly name alternatives or say when not to use this tool, but the purpose is specific enough that an agent can infer the right use case.
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.
find_products1 field changedInput schema / properties / teenAdded value: +{
+ "description": "Include teen / tween lines (default false: adult lines only).",
+ "type": "boolean"
+}absorbency_datasetabsorbency_translatefind_productsfind_sizeNeutral cross-brand bra-size translation and a live in-stock bra catalog by size.
Bra sizes from measurements, in each brand's own labels, with the confidence behind each.
S-to-F tier lists for 208 product categories. Every placement cited, with barcodes.
Neutral, sourced comparisons on any topic, in 32 languages. Each value links to its source.
Add one secure layer between your agents and this server.
