Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
17 tools with consistent naming (verb_noun pattern: create_event_operation_*) but critical gaps in schema visibility and parameter documentation. Tool descriptions are present (50-150 chars) but lack actionable context for LLM selection. Input schemas visible in the provided data show basic structure (event_guid, parent_operation_guid, branch, etc.) but parameter descriptions are minimal (10-30 chars). No output schemas documented. Two scope management tools (set_resource_scope, get_resource_scope) have better descriptions (~150 chars) but still lack depth. No evidence of error handling guidance, validation rules, or recovery paths. Schema completeness is low, parameters lack type constraints, enums, or format specifications beyond brief descriptions.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields (event_guid, operation_guid, etc.) without knowing response structure.
Parameter descriptions are minimal (10-30 chars) and lack actionable context. E.g., 'Branch type: NONE, ON_SUCCESS, or ON_ERROR' is an enum list, not a description explaining when to use each. LLMs cannot infer intent from bare enum values.
create_event_operation_alert
Recommendations
Add output schemas to all 17 tools. Document the response structure (e.g., { operation_guid: string, event_guid: string, status: 'created'|'failed', error?: string }). This enables LLMs to chain operations and extract IDs for subsequent calls.
Expand parameter descriptions to 50-100 chars with actionable context. E.g., 'branch: Execution path after this operation completes. Use NONE for sequential execution, ON_SUCCESS to run only if parent succeeds, ON_ERROR to run only if parent fails.'
Add enum constraints to 'branch' parameter across all tools. Define as enum: ['NONE', 'ON_SUCCESS', 'ON_ERROR'] in the JSON Schema, not just in the description.
Rewrite tool descriptions to include WHEN/WHY guidance. E.g., 'Create an ALERT operation to show a modal dialog to the user. Use this when you need to notify the user of an error, warning, or important information. Pair with ON_ERROR branch to show alerts on failure.'
Add error handling guidance to tool descriptions. E.g., 'If event_guid is not found, call get_resource_scope() to verify the current resource context. If parent_operation_guid is invalid, use ROOT for event-level operations.'
Create a VALIDATION_ELEMENTS event operation (validate form elements)
get_resource_scoperead onlysource verified65/100
Return the current MCP resource scope (``resource-type`` + ``resource-ref-id``) for this run. Use when unsure what the active Studio resource context is. get/list tools do not change scope by themselves.
set_resource_scopewritesource verified70/100
Set MCP ``resource-type`` / ``resource-ref-id`` for subsequent tool calls in this run. Call whenever the Studio resource you will use next is different from the current scope — including: After a successful ``create_*`` (use the returned type + guid, prefer ``createdResource`` when present), After get/list, before list/get/mutate against another existing resource. For page/layout UI design, keep scope on ``page``/``layout`` — do not switch to ``component`` using the backing component guid. Safe to call again with the same type/id (no-op).
Parameter types and constraints not visible in schema. 'branch' should be an enum; 'condition_json' should specify JSON Schema format; 'parent_operation_guid' should clarify GUID format. Current schemas lack type definitions beyond string.
Tool descriptions lack WHEN/WHY context. E.g., 'Create an ALERT event operation' does not explain when to use ALERT vs CONFIRM vs NAVIGATE. LLMs cannot disambiguate between 15 similar create_event_operation_* tools without clear selection guidance.