Skip to main content
Glama
Sign In

Widely

by com.widely-mobile
OverviewDiscussionsAdmin

Propose CRM client visibility

crm_propose_client_visibility
DestructiveIdempotent

Applies the visibility choices passed on this call. Sets what this business shows its clients on the minisite and in the client portal. Confirm the choices with the owner in the chat, then call this tool. It applies at once. Do not send them to the app to approve it. model is the list. phone_link_field ties a row to that client's verified phone. shared true shows the named rows of a list with no phone link to every client. shared_fields and client_visible_fields are the fields to show. The business chooses those fields, including a phone or a personal field. client_visible_actions are the actions a client may run. client_visible_records are the record ids to show. A field, action, or record you leave out is hidden. client_access true opens the portal and false closes it. A field, record, or action that is not on this list is refused. A phone-linked list is shown only to the client that row belongs to. The result is what clients now see. The audit log records it.

Input Schema

NameRequiredDescriptionDefault
modelYesList name on this account.
sharedNoWhen true, every client sees the named rows of this list. Refused when this list has a phone link, including a link through another record.
client_accessNoTrue opens the client portal. False closes it. It applies now.
shared_fieldsNoFields every client may see. Name each one. The business chooses, including a phone or a personal field. On a shared list these are the fields shown. On a related row they are the names shown instead of ids.
phone_link_fieldNoField that stores the client's phone in E.164, so a row belongs to that client. Pass an empty string to clear it. Omit it to keep the current link.
client_visible_fieldsNoField names a client may see. A field you leave out is hidden.
client_visible_actionsNoAction names a client may run. An action you leave out is hidden.
client_visible_recordsNoRecord ids a client may see. A record you leave out is hidden.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changed
    • changedInput schema / anyOf
      Previous value: -[
-  {
-    "required": [
-      "phone_link_field"
-    ]
-  },
-  {
-    "required": [
-      "shared"
-    ]
-  },
-  {
-    "required": [
-      "shared_fields"
-    ]
-  }
-]New value: +[
+  {
+    "required": [
+      "phone_link_field"
+    ]
+  },
+  {
+    "required": [
+      "shared"
+    ]
+  },
+  {
+    "required": [
+      "shared_fields"
+    ]
+  },
+  {
+    "required": [
+      "client_access"
+    ]
+  }
+]
    • changedInput schema / properties / client_access / description
      Previous value: -"When set, the proposal also opens or closes the client portal."New value: +"True opens the client portal. False closes it. It applies now."
    • changedInput schema / properties / client_visible_actions / description
      Previous value: -"Action names a client may run."New value: +"Action names a client may run. An action you leave out is hidden."
    • changedInput schema / properties / client_visible_fields / description
      Previous value: -"Field names a client may see."New value: +"Field names a client may see. A field you leave out is hidden."
    • changedInput schema / properties / client_visible_records / description
      Previous value: -"Record ids a client may see."New value: +"Record ids a client may see. A record you leave out is hidden."
    • changedInput schema / properties / phone_link_field / description
      Previous value: -"Field that stores the client's phone number in E.164. Omit this when shared is true."New value: +"Field that stores the client's phone in E.164, so a row belongs to that client. Pass an empty string to clear it. Omit it to keep the current link."
    • changedInput schema / properties / shared / description
      Previous value: -"When true, every client sees the approved rows of this list. Refused when this list has a phone link, including a link through another record."New value: +"When true, every client sees the named rows of this list. Refused when this list has a phone link, including a link through another record."
    • changedInput schema / properties / shared_fields / description
      Previous value: -"Fields every client may see. Name each one. A phone, an email, or a personal field is refused. On a shared list these are the fields shown. On a related row they are the names shown instead of ids."New value: +"Fields every client may see. Name each one. The business chooses, including a phone or a personal field. On a shared list these are the fields shown. On a related row they are the names shown instead of ids."
  2. Changed5 schema fields changed
    • addedInput schema / anyOf
      Added value: +[
+  {
+    "required": [
+      "phone_link_field"
+    ]
+  },
+  {
+    "required": [
+      "shared"
+    ]
+  },
+  {
+    "required": [
+      "shared_fields"
+    ]
+  }
+]
    • changedInput schema / properties / phone_link_field / description
      Previous value: -"Field that stores the client's phone number in E.164."New value: +"Field that stores the client's phone number in E.164. Omit this when shared is true."
    • addedInput schema / properties / shared
      Added value: +{
+  "description": "When true, every client sees the approved rows of this list. Refused when this list has a phone link, including a link through another record.",
+  "type": "boolean"
+}
    • addedInput schema / properties / shared_fields
      Added value: +{
+  "description": "Fields every client may see. Name each one. A phone, an email, or a personal field is refused. On a shared list these are the fields shown. On a related row they are the names shown instead of ids.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "model",
-  "phone_link_field"
-]New value: +[
+  "model"
+]
  3. Added

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses that changes take effect at once, that omitted fields/actions/records are hidden (the precise destructive effect behind destructiveHint=true), that invalid combinations are refused, that phone-linked lists are visible only to the owning client, and that the audit log records the change. That is the operational context an agent needs before a destructive write.

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 the action and the confirm-then-call instruction, with rules following in a sensible order. Some sentences duplicate the schema (client_access true opens the portal and false closes it) and the closing two lines are thin, but overall there is little wasted wording.

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 an 8-parameter destructive write with no output schema, it covers atomicity, refusal, visibility scoping, and feedback ("The result is what clients now see") plus audit logging. No output schema exists, so describing the return as the resulting client-visible state is adequate.

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 schema baseline is 3; the description adds cross-parameter rules not contained in the schema, notably that a phone-linked list is shown only to the client the row belongs to and that any field, record, or action omitted is hidden. Much of the rest restates the schema's own parameter text, which caps it below 5.

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?

States a specific verb and resource: it applies visibility choices controlling what the business shows clients on the minisite and client portal. It implicitly separates itself from the approval flow ("applies at once. Do not send them to the app to approve it") but never names crm_approve_client_visibility or crm_set_client_visibility, so sibling differentiation is left to inference.

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 a clear precondition and workflow: confirm the choices with the owner in the chat, then call; it applies immediately rather than routing to app approval. What is missing is explicit routing to the named alternatives in the catalog, so an agent must infer which sibling to use when it does want a draft/approval path.

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

All Widely toolsInspect
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