Parameter descriptions are minimal (avg 15-30 chars) and lack constraints, formats, or validation guidance. Example: 'S3 bucket name' does not explain valid characters, length limits, or naming conventions. LLMs cannot infer constraints and will pass invalid values.

Output schemas are not documented in visible source code. Tools return JSON (e.g., list_s3_buckets returns {success, bucketCount, buckets}), but there is no formal schema definition or field documentation. LLMs cannot plan downstream tool calls without knowing response structure.

Error handling is generic (catch Exception → return error JSON). No guidance on recovery, no error categorization (retryable vs. user-fixable vs. fatal), and no suggestions for next steps. Example: if delete_s3_bucket fails, the error does not tell the LLM whether to retry, check permissions, or ask the user.

Destructive operations (delete_s3_bucket, delete_s3_object, delete_eventhubs_namespace, delete_file_share, delete_directory) have no visible confirmation step, dry-run mode, or permission gate. Agents can delete resources without safeguards.

Naming ambiguity: list_eventhubs_namespaces vs get_eventhubs_namespace are similar in function but differ in plurality and discovery intent. Descriptions do not clarify when to use list vs get. LLMs may pick the wrong tool.

No pagination support visible in list operations (list_s3_buckets, list_eventhubs_namespaces, list_file_shares, list_credentials). If these return many items, context window will be exhausted. Pagination tokens or limits should be documented.

Resource group and subscription ID parameters are optional with no default explanation. Unclear whether these inherit from context (current credential selection) or fail silently if omitted.