This server has severe definition quality gaps. Tool descriptions are present but often generic (e.g., 'Retrieve cached LinkedIn job listings' lacks context on when to use it vs fetch-linkedin-jobs). Most critically, input schemas are either missing or inferred from code rather than explicitly registered. Parameters lack type definitions in visible schema declarations. No output schemas are documented. Error handling is absent, tools return raw HTTP errors without recovery guidance. The server conflates multiple concerns (e.g., naukri-auto-apply combines scraping, question-answering, and job logging). Tool names lack clarity: 'log-applied' vs 'log-manual-job' are confusingly similar; 'fetch-linkedin-jobs' vs 'fetch-linkedin-jobs-apify' vs 'get-linkedin-jobs' create ambiguity. No tool declares what it modifies or whether it's idempotent. Security-critical: get-config exposes API keys as tool output.

• Document output schemas for all tools. Example: get-jobs should return {jobs: [{id, title, company, location, source, status, appliedAt}], total: number}. This enables LLMs to chain calls and extract required fields.
• Add explicit input schemas with type definitions and enums for all tools. E.g., naukri-auto-apply.target should be {type: 'number', minimum: 1, maximum: 500, description: 'Number of jobs to process (default 50)'}.
• Rename tools for clarity: 'fetch-linkedin-jobs' → 'fetch-linkedin-jobs-by-search', 'fetch-linkedin-jobs-apify' → 'fetch-linkedin-jobs-apify-actor', 'get-linkedin-jobs' → 'get-cached-linkedin-jobs'. Distinguish by source/method in the name.
• Remove API keys from get-config output. Store config server-side; expose only non-sensitive fields (e.g., configured_sources: ['linkedin', 'naukri']). Inject secrets via environment variables.
• Add error handling with recovery guidance. E.g., if naukri-auto-apply fails: return {error: 'Naukri login failed. Check credentials in set-config.', retryable: true, nextStep: 'Call set-config with updated apifyKey'}.