Skip to main content
Glama
MCP Business Tools

MCP Business Tools

by danielpdev

search_inventory

Search synthetic inventory records by query to check stock availability without changing inventory data.

Instructions

Search synthetic inventory. Does not mutate stock.

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": "search_inventory"
  }
}

Input Schema

NameRequiredDescriptionDefault
queryNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3/5.0
Behavior3/5

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

With no annotations, the description carries the full burden, and 'Does not mutate stock' is a genuine read-only disclosure that an agent needs. Beyond that it says nothing about permission requirements, result limits, or what an empty query does (the schema defaults query to ""), leaving meaningful behavioral gaps.

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?

Two short, front-loaded sentences with no filler. The brevity is efficient, though it shades into under-specification rather than wasting words.

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

Completeness3/5

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

An output schema exists, so return values need not be described, and there is only one optional parameter. Still, the query semantics and the routing relative to prepare_order are missing, which leaves the definition only minimally sufficient for a search entry point.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% and the single 'query' parameter is undocumented anywhere. The description does not explain matching semantics (substring, fuzzy, exact) or whether the default empty string returns everything, which is the most consequential ambiguity for a search tool.

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 and resource ('Search synthetic inventory') and hints that the data is synthetic/test. It does not explicitly contrast with the sibling prepare_order, but the search-vs-prepare distinction is reasonably evident from the verbs.

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

Usage Guidelines2/5

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

There is no statement of when to use this search versus prepare_order, nor any prerequisite or exclusion. The only usage-adjacent signal is 'Does not mutate stock', which implies a read-only path but never says when that path is the right one.

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

Deploy Server

Other Tools