An MCP server providing tools for Twitter/X posting, local file operations, GitHub data fetching, Telegram messaging, resume processing, and job matching with AI enrichment
Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This MCP server exhibits significant definition quality gaps across nearly all dimensions. Of 16 tools, 2 lack input schemas entirely (enrich-resume-with-ai, score-job-match), making them non-functional for LLM agents. Naming conventions are inconsistent, some follow verb_noun (create_post, read_file) while others use hyphenated kebab-case (greeting-template, start-notification-stream, job-score-matcher) that does not align with standard MCP tool naming. Descriptions are present but generic and often too brief (average ~40 chars); most lack context on when to use the tool or what it returns. Parameter descriptions are minimal or missing entirely for several tools. Output schemas are undocumented in the source, responses are hardcoded text/JSON strings with no formal structure declared. Error handling is rudimentary (basic try-catch blocks returning error.message strings) with no actionable recovery guidance. Security issues include hardcoded Twitter API credentials in the code and no validation of user-supplied file paths (potential traversal attacks on read_file, read_directory, read-local-resume). Tools like create_post and send-telegram-message are destructive but lack confirmation/dry-run patterns. Overall, this server reads as an early-stage prototype rather than production-ready tooling.
Tool descriptions are generic and under 60 characters for most tools; lack context on when to use, prerequisites, or return format. Baseline for production is 100-200 chars.
Rename all kebab-case tools to snake_case verb_noun format: greeting_template, start_notification_stream, job_score_matcher, github_user_fetcher, github_readme_fetcher, github_file_fetcher, github_repo_structure, github_languages, send_telegram_message, read_local_resume.
Add formal input and output schemas for enrich-resume-with-ai and score-job-match. Document required parameters (e.g., resume text, job description) and expected response fields.
Expand tool descriptions to 100-200 chars. For each tool, answer: What does it do? When should the LLM call it? What does it return? Example: 'read_file: Reads and extracts text content from local files (TXT, PDF). Use this to load resume, code snippets, or document content for analysis. Returns file text, size, and encoding type.'
Document output schemas in tool definitions. Declare the response structure: {content: [{type: 'text' | 'resource' | 'image', ...}], metadata?: {...}, isError?: boolean}. This lets LLMs parse responses reliably.
Add validation to file system tools: sanitize paths to prevent traversal (reject paths containing '..'), enforce allowlist directories, and return clear errors like 'Invalid path: must be within /home/user/documents'.
Implement confirmation pattern for destructive tools. Add a 'dry_run' or 'confirm' parameter to create_post and send_telegram_message. Return a preview and require explicit confirmation before executing.
Wrap Twitter credentials in a secret injection pattern: store in .env, never pass as parameters, validate at server startup. Log successful authentication without revealing secrets.
Spec posture evidence
Inferred effective spec: 2026-07-28+.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↓ 2 points across a rubric change (v1 → v2)
44/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
F
44
2026-07-28+
v2
2026-03-09
F
46
-
v1
github-user-fetcherread onlysource verified58/100
Fetches GitHub user information and repositories by username. If repo is not provided, fetches all repos for the user.
greeting-templateread onlysource verified40/100
A simple greeting prompt template
job-score-matcherread onlysource verified48/100
Matches job descriptions with candidate resumes and provides a compatibility score
read-local-resumeread onlysource verified58/100
Reads a local PDF resume file and extracts text content
read_directoryread onlysource verified60/100
Lists all files and folders in a given directory
read_fileread onlysource verified58/100
Reads the contents of a any type of file(pdf or text) from the local system
Output schemas are not documented. Responses are hardcoded as {content: [{type: 'text', text: string}]} with optional metadata, but this structure is not declared in tool definitions, forcing LLMs to guess the response shape.
File system tools (read_file, read_directory, read-local-resume) accept user-supplied paths with no validation; vulnerable to path traversal attacks (e.g., ../../etc/passwd). Input must be sanitized.
Twitter API credentials (appKey, appSecret, accessToken, accessSecret) are hardcoded in mcp.tool.js via environment variables but not validated or wrapped in a secret injection pattern. If credentials leak, they are exposed in logs and parameter traces.
Error responses are raw error.message strings with no categorization (retryable vs fatal), no recovery guidance, and no field validation feedback. Example: 'Error reading file: ENOENT' does not tell the LLM what to do next.
Parameter descriptions are minimal or absent. Many params lack format/constraint guidance (e.g., 'directory' param in read_directory does not specify absolute vs relative, or character limits; 'media' param in create_post does not explain accepted file types).
No pagination or result-limiting for tools returning large datasets (e.g., github-user-fetcher could return hundreds of repos, github-file-fetcher returns entire file content unfiltered). No limit parameter; risk of context window exhaustion.
GitHub tools return raw API responses (JSON.stringify with null, 2 indentation). Should be stripped of metadata (pagination, user audit fields) and shaped for agent consumption.
Enhance error responses with recovery guidance. Instead of 'Error reading file: ENOENT', return 'File not found: /path/to/file. Check the path is correct and the file exists. Available files in /path/to: [list]'.
Add format/constraint descriptions to all parameters. Example: 'directory: Absolute or relative path to the directory to list. Must be readable by the server process. Relative paths are resolved from the current working directory.'
Add pagination to github-user-fetcher (limit default 20, offset/page param) and github-file-fetcher (return first 10KB with truncation warning). Add explicit result-size limits to read_directory.
Shape GitHub API responses: strip audit fields, pagination metadata, and node_ids. Return only: {repositories: [{name, url, description, languages: [...]}]} for user fetcher, {readme_text, last_updated} for readme fetcher.
Add test cases validating each tool's input schema, descriptions, and error handling. Use MCP SDK test utilities to verify tool registration and response shapes match schema.
Document parameter relationships and constraints. Example: 'media param in create_post accepts array of file paths (JPG, PNG, GIF, MP4 up to 15MB each) or empty array to send text-only tweet.'
Implement rate limiting on GitHub API tools (50 calls/minute default) to prevent agent runaway. Return clear rate-limit error: 'GitHub API rate limit exceeded. Retry after 60 seconds.'
Add idempotency hints and scope declarations. Document which tools are read-only (github-* tools) vs write (create_post, send_telegram_message). Annotate schema with {readOnlyHint: true} for GET-like tools.