request_workspace_customizationSubmit a plain-language request to the authenticated business's Customize Workspace builder. This is the same action as entering the request in LocalTry and pressing Send request; LocalTry owns the queued engineering work, testing, deployment, history, and restore point.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate this is not read-only or destructive. The description adds useful behavioral context: the request is queued asynchronously, LocalTry owns the engineering work, and history/restore points are maintained. This goes beyond the structured fields and helps the agent predict what happens after the call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the action, and every phrase adds information about scope or consequences. There is no redundant restatement of the tool name or properties.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with annotations, the description covers the action and downstream ownership well. However, with no output schema it does not state what the caller receives (e.g., request ID or confirmation), and it misses the opportunity to point to get_workspace_customization_status for tracking the queued work.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description carries the burden for parameter meaning. It does add that 'request' is a plain-language text request, matching LocalTry's input, but it provides no examples or guidance on what makes a good request. The schema's min/max length constraints are still the main source of parameter detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb, 'Submit', names the resource ('Customize Workspace builder'), and clarifies the input is a plain-language request. This clearly differentiates it from sibling tools like get_workspace_customization_status or restore_workspace_version.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this mirrors the LocalTry 'Send request' action, but it gives no explicit guidance on when to choose this tool over siblings, nor any conditions or prerequisites. There is no mention of alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Several tools overlap in purpose: get_workspace_overview and search_localtry_features both return feature/capability catalogs, and get_workspace_customization_status/list_workspace_versions overlap with customization history. run_localtry_command also acts as a generic catch-all that could subsume most of the specific action tools, making selection ambiguous.
Most tools follow a clear verb_noun pattern (get_*, search_*, create_*, run_*, list_*, restore_*, request_*). Minor deviations like create_or_update_crm_record and run_localtry_command introduce slight inconsistency, but the overall convention is predictable.
With 12 tools, the server is well-scoped for a platform that covers CRM, workflow agents, workspace customization, and feature discovery. Each tool addresses a distinct functional area without excessive fragmentation.
The surface covers the main workflows: CRM upsert/search, workflow agent creation and execution, customization request/status/version restore, and feature discovery. Some lifecycle gaps exist (no delete CRM record, no update/delete agent or workflow), but the generic run_localtry_command can partially compensate.