Three tools with minimal definitions. All lack verb-prefixed names (applications, sites, users are nouns, not actions). Descriptions are generic and under 100 chars, insufficient for LLM tool selection. Input schemas present but trivial: single optional 'name' string with no type validation, enums, or constraints. No output schema documented. No error handling guidance. No parameter descriptions beyond 'The name of the X'. Tools appear read-only but lack explicit idempotent/readOnly annotations. No pagination support despite APIs returning collections. Naming violates pattern:tool (should be list_applications, get_sites, search_users). Descriptions fail to answer WHEN to use each tool or what distinguishes them.

• Rename tools to action verbs: 'list_applications', 'search_sites', 'get_users'. This matches pattern:tool and helps LLMs infer intent from the name alone.
• Expand descriptions to 150 - 250 chars. Include WHAT (retrieves applications from Microsoft Graph), WHEN (when you need to find or list applications), and RETURN (returns application IDs, display names, and app IDs). Example: 'List or search Microsoft Graph applications by display name. Returns application IDs, display names, app IDs, and publisher domains. Call this to discover available applications before performing operations.'
• Add parameter constraints: specify that 'name' is a display name substring (case-insensitive), max 255 chars, optional. If no name provided, returns all applications (with limit). Add description: 'Display name or substring to filter applications. If omitted, returns all applications (limited to 50 results).'
• Document output schema in tool registration. Specify that response is a JSON object mapping application IDs to objects with fields: id, displayName, appId, publisherDomain, createdDateTime. Include example structure.
• Add pagination parameters: 'limit' (1 - 100, default 20) and 'offset' (0+, default 0). Update description to mention pagination. Return total_count in response so LLM knows if more results exist.