wals.pro AI 4 weclapp

Read settings

read_settings

Read-onlyIdempotent

Read one settings/integration domain by key, redacted server-side; without domain_key, list the domain catalog.

Covers configuration and integration surfaces that are not part of the generic entity allowlist (webhooks, external connections, mail accounts, number ranges, helpdesk config, …). Secret/transport fields are always masked. Called without domain_key it returns the static catalog of readable domains plus the audit-log enums for read_activity_log — no weclapp call, no ERP data; all other arguments are ignored in catalog mode.

Args: domain_key: Exact catalog key (e.g. "webhook"). Omit to list the catalog of valid domain keys and audit-log enums. filters: Objects like {"field": "settingsKey", "op": "like", "value": "x"}. For domain_key="sops" (house rules) one object {target_entity, operation, workflow_scope}. properties: Field projection; secret fields stay masked even if requested. Ignored for projection-locked domains (e.g. mailAccount), which return a fixed safe field set. entity_id: Fetch one record by id instead of the collection. limit: Max collection rows (default 20, capped at 100).

Returns: Domain mode: {source, domain_key, kind, title, results, untrusted_content, redaction}. Hidden key/value stores return their value as a shape summary, never raw content. Catalog mode: {source, domains, activity_log, redaction, usage}.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No
`filters`	No
`entity_id`	No
`domain_key`	No
`properties`	No
`correlation_id`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 27, 2026

changedInput schema / properties / filters / anyOf

Previous value: -[
-  {
-    "items": {
-      "additionalProperties": true,
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "items": {
+      "additionalProperties": true,
+      "type": "object"
+    },
+    "type": "array"
+  },
+  {
+    "additionalProperties": true,
+    "type": "object"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / limit / anyOf

Added value: +[
+  {
+    "type": "integer"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / limit / default
```
Previous value: -20New value: +null
```
removedInput schema / properties / limit / type
```
Removed value: -"integer"
```

First observedSep 25, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantial context beyond them: redaction happens server-side, secret/transport fields are always masked even when explicitly requested, projection-locked domains (mailAccount) return a fixed safe field set, hidden key/value stores return only a shape summary, and catalog mode makes no backend call. The untrusted_content flag and 'no ERP data' note are real behavioral disclosures.

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 summary sentence captures both modes before the detail blocks, and the Args/Returns structure is scannable. It is somewhat long, and since an output schema exists the Returns block is partly redundant, though the redaction/kind details it adds do earn some of their place.

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 complex, 6-parameter, dual-mode tool, the description covers mode selection, redaction guarantees, projection locking, filtering shape, and pagination caps. Combined with the existing output schema and readOnly annotations, an agent has everything needed to invoke it correctly; the lone gap is the undocumented correlation_id.

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 0%, so the description must compensate, and it largely does: domain_key semantics and examples, filters syntax with a worked example and the special sops shape, properties projection + masking caveat, entity_id single-record behavior, and the limit default/cap. Only correlation_id is left entirely undocumented, so it falls short of full coverage.

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 (read one settings/integration domain by key) and immediately clarifies the dual-mode behavior (catalog listing when domain_key is omitted). It explicitly carves out the scope it covers — 'configuration and integration surfaces that are not part of the generic entity allowlist' — which lets an agent separate it from get_entity/search_entities 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 clear when-to-use signals: omit domain_key to list the catalog, pass entity_id to fetch a single record, and catalog mode is noted as side-effect free with all other args ignored. It implies a boundary against the generic entity tools but never names an alternative sibling (e.g. get_entity, get_reference_data) or states when NOT to use this tool, so exclusions are left to inference.

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

All wals.pro AI 4 weclapp 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?