DodoDentist Dental Clinic

Check practice stock

list_inventory_items

Read-onlyIdempotent

Use this when someone asks how much of a supply is left in their dental practice's stock or what is running low. Returns up to 100 stock items with unit, quantity, minimum and a low-stock flag. Not for treatment prices.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_inventory_items"
  }
}

Input Schema

Name	Required	Description
`limit`	No	Maximum number of items (default 50, maximum 100).
`search`	No	Only items whose name contains these words.
`clinicId`	No	Id of the practice, from list_clinics. Leave it out when the user has one practice.
`lowStockOnly`	No	Only items at or below their minimum quantity.

Output Schema

Name	Required	Description	Default
`count`	Yes
`items`	Yes
`hasMore`	Yes
`clinicId`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is fully covered. The description adds the result cap ('up to 100 stock items') and the shape of the returned rows, but it never says what happens when more than 100 items exist — truncation versus paging is left unknown.

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

Conciseness5/5

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

Three tight sentences: trigger condition first, then returned content and cap, then the exclusion. There is no hedging, restatement of the title, or filler.

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 read-only list tool with a full output schema and 100% parameter coverage, the description supplies the usage trigger and the exclusion that structured fields cannot express. The only shortfall is unspecified behavior above the 100-item cap, which matters for a tool that may hit it in a large practice.

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 limit, search, clinicId, and lowStockOnly are all documented in structured data, establishing the baseline of 3. The description only obliquely echoes lowStockOnly via 'what is running low' and adds no filtering or format detail beyond the schema.

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

Purpose5/5

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

The description pairs a concrete action (list stock items) with the domain resource ('a supply ... in their dental practice's stock') and names the fields returned (unit, quantity, minimum, low-stock flag). The closing exclusion 'Not for treatment prices' separates it from the pricing/procedure siblings such as list_procedures.

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

Usage Guidelines4/5

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

It gives a clear triggering condition ('when someone asks how much of a supply is left ... or what is running low') and a negative case ('Not for treatment prices'). What it omits is naming the write counterpart set_inventory_quantity, so an agent must infer that adjusting quantities belongs elsewhere.

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

All DodoDentist Dental Clinic 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?