REGULARUS

List required documents

list_documents

List the documents needed for the safety report by product type, number of recipes and varieties, manufacturer and package (recipe with quantities, raw material data sheets, fragrance documents, stability test, GMP, packaging, label draft).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "product_type": "<product_type>"
    },
    "name": "list_documents"
  }
}

Input Schema

Name	Required	Description
`lang`	No	Language of the texts in the response and on the confirmation page (default en).
`maker`	No	Who manufactures the products (does not change the price).
`package`	No	Package; without it all three are returned with a recommendation.
`recipes`	No	Own recipes (base formulas) per product type (default 1).
`varieties`	No	Total varieties per product type, base products included (e.g. one recipe with three fragrances: recipes=1, varieties=3). Default: same as recipes.
`product_type`	Yes	Product type; several separated by commas, with recipes and varieties in the same order.
`claims_review`	No	Review of advertising claims per variety (not with claims=no).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 14, 2026

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description carries the full disclosure burden. 'List' implies a read-only operation and the parenthetical enumeration compensates somewhat for the missing output schema by revealing the kinds of documents returned, but no permissions, idempotency, rate limits, or side effects are disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with the verb first and the qualifying factors following. The long parenthetical enumeration of document types makes it denser than ideal, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter, read-style tool with no output schema, the description usefully sketches the returned content (recipe with quantities, SDS, fragrance documents, stability test, GMP, packaging, label draft) and identifies the major inputs. Defaults and enum meanings are handled by the rich schema, so little is missing.

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 description coverage is 100%, so the schema already documents every parameter including defaults and enums. The description restates the main drivers (product type, recipes/varieties, manufacturer, package) but adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb ('List') and resource ('documents needed for the safety report') plus the drivers that shape the result (product type, recipes, varieties, manufacturer, package). It is clear enough to distinguish from the siblings get_fixed_price and verify_report, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrasing 'needed for the safety report' implies the workflow context in which the tool is used, but there is no explicit when-to-use, when-not-to-use, or routing advice relative to get_fixed_price or verify_report. Usage must be inferred from the domain framing.

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

All REGULARUS tools Inspect

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

Need Help?