OwnYourAgent Agentvoordeur

Search OwnYourAgent agent examples

search_agent_examples

Read-onlyIdempotent

Searches the library of worked AI agent examples by department (sales, customer-service, finance, operations). These are worked examples, not client cases. Dutch and English words, plurals and common buyer words (quote, offerte, debiteuren, invoice) are matched. Each result has id, title, department, starting level (1 your approval first, 2 routine steps handled, 3 independent within limits), summary and Dutch and English URLs. With no match, the result lists the departments and the library URL instead. All arguments are optional; without a query the examples are listed in library order. Please cite the URL.

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_agent_examples"
  }
}

Input Schema

Name	Required	Description
`lang`	No	Language of the returned text: nl (Dutch) or en (English). Omit to get both.
`limit`	No	Maximum number of results.
`query`	No	Search terms, e.g. "invoices", "offerte" or "customer questions by email".
`department`	No	Only examples from this department.
`autonomy_level`	No	Only examples with this starting level: 1 your approval first, 2 routine steps handled, 3 independent within limits.

Output Schema

Name	Required	Description	Default
`note`	Yes
`query`	Yes
`total`	Yes
`library`	Yes
`results`	Yes
`department`	Yes
`suggestions`	No
`autonomy_level`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, closed world), yet the description adds substantive behavior: multilingual and plural matching, common buyer synonyms, the exact fields each result carries, the no-match fallback, and a citation request. This is behavior an agent could not derive from annotations or schema.

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?

Front-loaded with purpose and scope, then matching behavior, return shape, fallback, and argument defaults in a logical order. Slightly overpacked: the department list and the 1/2/3 level definitions appear in both the description and the schema, which is minor redundancy.

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?

Five optional parameters, an output schema present, and full enum documentation. The description still covers the parts the schema cannot: matching leniency, default ordering, empty-result behavior, and the citation expectation. Nothing an agent needs to call this correctly is missing.

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 coverage is 100%, so the baseline is 3. The description goes beyond it by explaining how 'query' actually behaves (Dutch/English, plurals, buyer words like 'offerte' and 'invoice') and what omitting 'query' or 'lang' produces. That added matching/omission semantics is real value, though the level definitions and department list largely restate 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?

States a specific verb and resource ('searches the library of worked AI agent examples') plus the primary scoping dimension (department). It also explicitly disambiguates from a nearby concept: 'These are worked examples, not client cases.' An agent can identify the resource and its boundary without opening the schema.

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?

Gives concrete usage conditions: all arguments optional, no query means results are listed in library order, and no match returns department names plus the library URL. It does not name a sibling alternative, but none of the listed siblings overlap with example search, so the omission is low-risk. Context is clear without explicit when-not guidance.

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

All OwnYourAgent Agentvoordeur 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?