Skip to main content
Glama
Sign In

Supero

by io.github.supero-platform
OverviewDiscussions(2)Admin

crud_search

Read-only

Search/list objects of any type in the current domain. Use schema_list first to discover available object types. System types: project, tenant, user_account, api_key, connector, audit_log, schema_registry, client_sdk, connector_execution, connector_plugin. Domain types vary per domain (e.g. customer, invoice, appointment, vehicle).

Input Schema

NameRequiredDescriptionDefault
sortNoOptional sort: a field name ('amount', or '-amount' for descending), {"field": "amount", "order": "desc"}, or a list of those.
limitNoMax results (default: 100, max 1000)
filterNoOptional boolean filter tree for and/or/not logic, e.g. {"op": "or", "conditions": [{"status": "open"}, {"amount": {"gt": 500}}]}. Use `filters` for simple AND-ed conditions.
offsetNoSkip N results for pagination
tenantNoOptional tenant name to scope the search to (multi-tenant apps: verify a specific named tenant's data). Omit for single-tenant apps — the session/API-key tenant is used.
filtersNoFilter criteria keyed by field. A plain value is equality (e.g. {"status": "active"}); an object of operators compares (e.g. {"amount": {"gte": 10, "lt": 100}}). Operators: eq, ne, gt, gte, lt, lte, in, not_in, between, contains, starts_with, ends_with, regex, exists.
object_typeYesThe object type to search (e.g. 'customer', 'project', 'tenant', 'connector')

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • removedInput schema / properties / detail
      Removed value: -{
-  "description": "Include full object data (default: true)",
-  "type": "boolean"
-}
    • addedInput schema / properties / filter
      Added value: +{
+  "description": "Optional boolean filter tree for and/or/not logic, e.g. {\"op\": \"or\", \"conditions\": [{\"status\": \"open\"}, {\"amount\": {\"gt\": 500}}]}. Use `filters` for simple AND-ed conditions.",
+  "type": "object"
+}
    • changedInput schema / properties / filters / description
      Previous value: -"Filter criteria as key-value pairs (e.g. {\"status\": \"active\"})"New value: +"Filter criteria keyed by field. A plain value is equality (e.g. {\"status\": \"active\"}); an object of operators compares (e.g. {\"amount\": {\"gte\": 10, \"lt\": 100}}). Operators: eq, ne, gt, gte, lt, lte, in, not_in, between, contains, starts_with, ends_with, regex, exists."
    • changedInput schema / properties / limit / description
      Previous value: -"Max results (default: 100)"New value: +"Max results (default: 100, max 1000)"
    • addedInput schema / properties / sort
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "object"
+    },
+    {
+      "items": {
+        "type": "object"
+      },
+      "type": "array"
+    }
+  ],
+  "description": "Optional sort: a field name ('amount', or '-amount' for descending), {\"field\": \"amount\", \"order\": \"desc\"}, or a list of those."
+}
  2. First observed

TDQS

A3.8/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description adds that domain types vary per domain and that the domain context scopes results, which is useful. It says nothing about result shape, pagination behavior, or default limits beyond what the schema already documents.

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, front-loaded with the core action, then the prerequisite, then the type reference. Every sentence earns its place; the type list is dense but genuinely useful lookup content.

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 search with a fully documented schema, the description covers purpose, prerequisite, and valid types adequately. There is no output schema, so a brief note on return shape (list vs paged envelope, total counts) would be the only missing piece. Otherwise sufficient to invoke correctly.

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%, including sort, filter/filters distinction, limit, offset, and tenant semantics, so the schema carries the full parameter burden. The description only contributes the object_type value space. Baseline 3 applies since it adds little beyond structured fields.

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?

Specific verb and resource: "Search/list objects of any type in the current domain," and it names the domain-scoping. It enumerates concrete system and domain object types, so an agent knows exactly what universe it operates in. It stops short of explicitly contrasting with crud_get for single-object retrieval, so sibling differentiation is only implied by the verb.

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 an explicit prerequisite workflow: "Use schema_list first to discover available object types," which is actionable guidance an agent can follow. The type enumeration doubles as a validity reference. It does not state when to prefer crud_get or when a search is inappropriate, so exclusions are absent.

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

All Supero toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources