Conduit Agentic Commerce

Stock in your own system

inventory_levels

Read-onlyIdempotent

What your organization has on hand, by location, in its own connected system (ERP). Pass skus or query. Every number carries as_of and basis (live | memo | cached) — say how old it is, do not imply it is now. Needs inventory permission. This is your OWN stock; a supplier's stock is supply_availability.

Input Schema

TableJSON Schema

Name	Required	Description
`skus`	No	Item codes in your own system, e.g. ["CART-6040"]. Pass skus or query
`fresh`	No	Ask the system now instead of reading the last value (slower, rate limited)
`query`	No	Free-text item search in your own system, e.g. "carton"
`agent_id`	Yes	Agent id; its organization owns the connected system
`connection_id`	No	Which connected system, when the org has several
`session_token`	No	Session token from agent_authenticate — required whenever agent_id is passed

Output Schema

TableJSON Schema

Name	Required	Description	Default
`hint`	No
`next`	No
`as_of`	No
`basis`	No
`error`	No
`detail`	No
`system`	No
`freshness`	No
`connections`	No
`availability`	No
`connection_id`	No
`could_not_reach`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedSep 24, 2026
- addedOutput schema / properties / next / properties / args / additionalProperties / anyOf
```
Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  }
+]
```
- removedOutput schema / properties / next / properties / args / additionalProperties / type
```
Removed value: -"string"
```
AddedSep 20, 2026

TDQS

A4.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable context beyond that: it explains that every number carries as_of and basis (live/memo/cached) and instructs the agent to treat data as not necessarily current, plus the permission requirement. This is meaningful behavioral disclosure not present in annotations.

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?

Two concise sentences. The first sentence states purpose and input method; the second adds freshness semantics, permission, and sibling differentiation. Every clause carries information, and the most critical distinction (own vs supplier) is placed at the end for emphasis. No wasted words.

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

Completeness5/5

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

For a tool with six parameters, an output schema, and annotations covering safety, the description covers all necessary context: scope, freshness semantics, permission, and the sibling alternative. The output schema presumably handles return value details, so nothing critical is missing. The description is complete and self-sufficient.

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

Parameters4/5

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

Schema description coverage is 100%, so each parameter is already documented. The description reinforces the key usage pattern 'Pass skus or query,' clarifying that these are alternative inputs, and emphasizes the 'fresh' parameter's rate-limiting behavior implicitly. While it doesn't add wholly new facts, it rephrases the essential selection logic in a way that aids correct invocation.

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 clearly states the tool returns inventory levels from the organization's own connected system, scoped by location, and explicitly contrasts it with supply_availability. The verb 'has on hand' plus the resource 'connected system (ERP)' makes the purpose unambiguous and distinguishes it from sibling inventory tools.

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

Usage Guidelines5/5

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

The description explicitly says 'This is your OWN stock; a supplier's stock is supply_availability,' naming the sibling to use instead. It also notes 'Needs inventory permission,' a prerequisite, and instructs to pass skus or query. This gives clear when-to-use and when-not-to-use guidance.

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

All Conduit Agentic Commerce 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?