Widely

Install a CRM template

crm_install_template

Destructive

Previews a starter template. Nothing is saved unless confirm is true. Pass the template name first. When the preview says needs_business_name, ask for the business name before the yes. A yes calls again with confirm true and that business_name. The install saves the lists and adds one menu item per list and dashboard cards taken from those lists. A list already in the menu, and a card with the same type, list, and view, stay. A menu or widgets block on the template is added instead of that derived layout. A row on each list is saved with the list.

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

Input Schema

Name	Required	Description
`name`	Yes	Starter template. The call previews it until confirm is true.
`confirm`	No	Must be true to install. Omitted or false returns the preview only.
`business_name`	No	Business name. Send it with the yes when the preview says needs_business_name.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 8, 2026

addedInput schema / properties / business_name

Added value: +{
+  "description": "Business name. Send it with the yes when the preview says needs_business_name.",
+  "type": "string"
+}

Changed1 schema field changedNov 1, 2026

changedInput schema / properties / name / enum

Previous value: -[
-  "clinic_appointments",
-  "lending_gmach",
-  "membership",
-  "sales_pipeline",
-  "service_bookings"
-]New value: +[
+  "clinic_appointments",
+  "lending_gmach",
+  "membership",
+  "prepaid_balance",
+  "sales_pipeline",
+  "service_bookings"
+]

AddedOct 31, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations flag destructiveHint=true and idempotentHint=false; the description turns that into concrete consequences by listing exactly what is written (lists, one menu item per list, dashboard cards, one row per list) and by making the default non-destructive unless confirm is true. It also resolves the conflict behavior ('a list already in the menu, and a card with the same type, list, and view, stay') and the override case for a template-supplied menu or widgets block. That is the merge/overwrite semantics an agent cannot get from the hint flags alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense and front-loaded with no filler, but the telegraphic phrasing costs clarity: 'A yes calls again with confirm true' and 'A list already in the menu, and a card with the same type, list, and view, stay' require re-reading. The information is worth the space; the presentation should be smoother.

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 destructive, non-idempotent two-phase write with no output schema, the definition covers workflow, conditional parameters, write scope, and conflict handling. The one soft spot is that the preview's return shape is only implied via the needs_business_name flag rather than named, so an agent still infers the rest of the preview payload.

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 parameter docs already stand on their own; the description adds the call sequence and the conditional dependency (business_name only when the preview says needs_business_name). The 'Pass the template name first' ordering is real procedural meaning beyond the schema.

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?

The description states a concrete two-phase verb+resource: 'Previews a starter template' then installs lists plus one menu item per list plus dashboard cards. It is clearly distinguishable from the sibling layout tools (crm_set_menu, crm_set_dashboard) because it says those structures are derived from the template rather than supplied. The opening could have led with 'install' instead of 'previews,' but it names both phases explicitly.

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?

It gives explicit conditions for the two calls: 'Pass the template name first,' and 'A yes calls again with confirm true and that business_name.' It also flags the needs_business_name branch, so the agent knows when to ask for a business name. It doesn't rule out alternatives such as hand-building the layout with crm_set_menu/crm_set_dashboard, which is the only missing piece.

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

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