Agent Action Gateway

Search orders

search_orders

Read-only

Find orders by customer name or email when the order ID is unknown; returns up to 10 matches, newest first.

Instructions

Find orders by customer name or email when the order ID is unknown. Returns up to 10 matching orders, newest first. Read-only.

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": {
      "query": "<query>"
    },
    "name": "search_orders"
  }
}

Input Schema

Name	Required	Description	Default
`query`	Yes	Customer name or email, e.g. "Daniel"

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and openWorldHint, so "Read-only" in the description is redundant, but the added facts "Returns up to 10 matching orders, newest first" disclose real result-set behavior (result cap and ordering) that structured fields do not carry. It leaves matching semantics (partial vs exact, case sensitivity) and the no-match case unstated, so it is strong rather than complete.

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 short sentences, with the purpose and the discriminating condition front-loaded ahead of return behavior. The only weak sentence is the redundant "Read-only," but it costs almost nothing.

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 one-parameter lookup with no output schema, this covers purpose, alternative condition, result cap and sort order — enough to call it correctly. The remaining gap is match semantics and empty-result behavior, which matters for an open-world search but is a modest omission.

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 coverage is 100% and the single parameter's description already specifies "customer name or email, e.g. 'Daniel'", so the description's restatement adds no new meaning. Baseline 3 applies when the schema carries the parameter burden.

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?

"Find orders by customer name or email" states a specific verb and resource, and the qualifier "when the order ID is unknown" distinguishes it from the get_order sibling without naming it. An agent can tell immediately what this tool does and what input it expects.

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?

The phrase "when the order ID is unknown" gives a clear selecting condition that implies get_order for known IDs, which is solid when-to-use guidance. It stops short of naming the alternative explicitly or stating exclusions, so it is not quite a 5.

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

Deploy Server