Which integrations are available for this server?

Provides tools to query live GitHub activity and statistics, including pull requests, profile stats, and contribution search.

How do I use Pavan Madduri — Personal Knowledge MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pavan Madduri — Personal Knowledge MCP Server Show me Pavan's latest GitHub activity" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Pavan Madduri — Personal Knowledge MCP Server

by pmady

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

Pavan Madduri — Personal Knowledge MCP Server

A Model Context Protocol (MCP) server that exposes my professional profile — certifications, industry articles, open source contributions, and live GitHub activity — as a queryable API for AI agents.

Why? Instead of a static resume, this is a Personal Knowledge API. Any AI agent (Claude, Gemini, Copilot) can query my career data in real-time. This is AI infrastructure, not just AI usage.

What's Inside

Resources (Static Data)

Resource URI	Description
`profile://about`	Bio, links, expertise areas
`profile://certifications`	CNCF Golden Kubestronaut (all 15 certs + LFCS)
`profile://articles`	9 industry articles (CNCF Blog, IEEE ComSoc, CloudNativeNow, PlatformEngineering.com, d7y.io)
`profile://open-source-summary`	26 PRs across 15 projects
`profile://contributions/cncf`	Detailed CNCF project PRs
`profile://contributions/aswf`	Detailed ASWF project PRs

Tools (Dynamic Functions)

Tool	Description
`search_contributions(project)`	Search contributions by project name
`search_articles(keyword)`	Search industry articles by keyword, category, or publication
`get_expertise(domain)`	Check expertise in a technical domain
`get_eb1a_evidence(criterion)`	Retrieve EB-1A extraordinary ability evidence
`get_github_activity(repo, limit)`	Live GitHub PR data via API
`get_github_stats()`	Live GitHub profile statistics
`get_profile_summary()`	One-page comprehensive summary

Related MCP server: GitHub MCP Server

Quick Start

Prerequisites

Python 3.11+
uv (recommended) or pip

Install & Run

# Clone
git clone https://github.com/pmady/pavan-profile-mcp.git
cd pavan-profile-mcp

# Option A: uv (recommended)
uv sync
uv run server.py

# Option B: pip
pip install -e .
python server.py

Environment Variables (Optional)

# For higher GitHub API rate limits (optional — works without it)
export GITHUB_TOKEN="ghp_your_token_here"

Connect to Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

{
  "mcpServers": {
    "pavan_profile": {
      "command": "uv",
      "args": ["--directory", "/path/to/pavan-profile-mcp", "run", "server.py"]
    }
  }
}

Restart Claude Desktop. You'll see the tools appear in the MCP panel.

Example Prompts

"What are Pavan's contributions to Dragonfly?"
"Show me his published articles on AI infrastructure"
"What EB-1A evidence does Pavan have for original contributions?"
"Get his latest GitHub activity"
"Does he have expertise in GPU scheduling?"

Connect to Other Clients

Cursor / Windsurf

Add to your MCP config:

{
  "pavan_profile": {
    "command": "uv",
    "args": ["--directory", "/path/to/pavan-profile-mcp", "run", "server.py"]
  }
}

Render (Public Hosting)

One-Click Deploy:

This server deploys on Render with HTTP transport for remote access.

Live Production Server: https://pavan-profile-mcp.onrender.com/mcp

Connect any MCP client to the remote endpoint:

{
  "mcpServers": {
    "pavan_profile": {
      "url": "https://pavan-profile-mcp.onrender.com/mcp"
    }
  }
}

Manual deployment:

Fork this repo
Go to Render Dashboard
Click "New" → "Blueprint"
Connect your forked repo
Render auto-detects render.yaml and deploys
Your MCP endpoint will be at https://<your-service-name>.onrender.com/mcp

Architecture

AI Agent (Claude / Gemini / Copilot)
        │
        ▼
┌─────────────────────────────┐
│   MCP Protocol (stdio/SSE)   │
├─────────────────────────────┤
│   FastMCP Server            │
│                             │
│   Resources:                │
│   ├── profile://about       │
│   ├── profile://certs       │
│   ├── profile://articles    │
│   └── profile://oss-summary │
│                             │
│   Tools:                    │
│   ├── search_contributions  │
│   ├── search_articles       │
│   ├── get_expertise         │
│   ├── get_eb1a_evidence     │
│   ├── get_github_activity ──┼──► GitHub API (live)
│   ├── get_github_stats    ──┼──► GitHub API (live)
│   └── get_profile_summary   │
│                             │
│   Data: data/profile.json   │
└─────────────────────────────┘

Project Structure

pavan-profile-mcp/
├── server.py              # MCP server — all resources and tools
├── data/
│   └── profile.json       # Structured profile data (certs, articles, PRs)
├── Dockerfile             # Railway/Render deployment
├── pyproject.toml         # Python project config
├── SKILL.md               # Smithery skill definition
├── smithery.yaml          # Smithery.ai config
├── claude_desktop_config.example.json
├── README.md
└── LICENSE

About the Author

Pavan Madduri — Senior DevOps/Platform Engineer

CNCF Golden Kubestronaut (all 15 CNCF certifications + LFCS)
Published author on CNCF Blog, IEEE ComSoc, CloudNativeNow, PlatformEngineering.com
26 PRs across 15 CNCF & ASWF projects (Dragonfly, Volcano, KEDA, Kubernetes, TiKV, OpenColorIO, and more)
Dragonfly Community Member (CNCF Incubating)

GitHub · LinkedIn · Blog

License

MIT

Available Tools

7 tools

get_eb1a_evidenceB

Retrieve evidence supporting a specific EB-1A extraordinary ability criterion.

ParametersJSON Schema

Name	Required	Description	Default
`criterion`	Yes	EB-1A criterion — one of: 'original_contribution', 'authorship', 'judging', 'membership', 'published_material', 'leading_role', 'high_salary', 'all'

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.2/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full behavioral burden. It does not disclose return behavior, error handling, authentication requirements, or any side effects. The minimal description lacks transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single concise sentence that front-loads the core action. However, it is slightly too minimal; a bit more context would improve without sacrificing conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and sibling tools, the description is adequate but not rich. It lacks context about the evidence structure or when to use alternatives, yet it is sufficient for a straightforward retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and includes a detailed list of valid criterion values. The description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'retrieve' and the specific resource 'evidence supporting a specific EB-1A extraordinary ability criterion'. It distinguishes from sibling tools like get_expertise or get_github_activity by focusing on EB-1A evidence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus siblings like search_articles or get_profile_summary. There is no mention of prerequisites or alternative tools for different criteria.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_expertiseB

Check if Pavan has expertise in a specific technical domain.

ParametersJSON Schema

Name	Required	Description	Default
`domain`	Yes	Technical domain to check (e.g. 'GPU', 'kubernetes', 'gitops', 'observability', 'security', 'AI', 'platform engineering')

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden but only says 'Check', implying a read-only query. It does not disclose side effects, permissions, or any behavioral traits beyond a simple check.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, well-structured sentence that immediately conveys the tool's purpose without extraneous words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with a single parameter and an output schema, the description is mostly complete. It explains the subject (Pavan) and the domain check, though it could hint at the output format or mention that it only covers Pavan.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a clear parameter description and examples. The tool description adds the specific context of checking for 'Pavan', but does not add meaning beyond the schema's existing documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Check') and the resource ('expertise in a specific technical domain') and ties it to a specific person ('Pavan'), making the purpose distinct from sibling tools like get_eb1a_evidence or get_github_activity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, conditions, or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_github_activityA

Fetch Pavan's latest GitHub pull requests (live from GitHub API).

ParametersJSON Schema

Name	Required	Description	Default
`repo`	No	Optional GitHub repo in 'owner/repo' format (e.g. 'dragonflyoss/client'). If omitted, fetches recent activity across all tracked repos.
`limit`	No	Max number of PRs to return (default 10, max 30).

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must carry the burden of behavioral disclosure. It mentions 'live from GitHub API' suggesting real-time data, but does not disclose rate limits, authentication needs, error handling, or that it is scoped to a specific user ('Pavan'). This lack of detail is a gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that is front-loaded with the action and resource. No extraneous words, achieving high conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool is simple (2 params, no nested objects, has output schema), the description is minimal but adequate. It doesn't explain output format (though output schema exists) or error scenarios. Could be more complete, but meets the minimum.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does not add any parameter information beyond what the schema already provides (repo format, limit default/max). Hence, no added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Fetch', the resource 'Pavan's latest GitHub pull requests', and the source 'live from GitHub API'. It distinguishes itself from sibling tools like get_github_stats (stats) and get_profile_summary by specifying pull requests as the focus.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for retrieving pull requests but does not explicitly state when to use this tool over alternatives like get_github_stats or search_contributions. No guidance on when not to use it is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_github_statsA

Fetch Pavan's live GitHub profile statistics (repos, followers, contributions).

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It states 'live' implying real-time data, which is a behavioral trait. However, it omits information about authentication requirements, rate limits, or any side effects. For a zero-parameter fetch, this is adequate but not thorough.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence that front-loads the action and resource, then lists examples. Every word adds value; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has an output schema (so return values are documented), no parameters, and the description lists key data points, it is complete for its complexity. The context signals indicate high schema coverage and no nesting, so the description suffices.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the baseline is 4 per instructions. The description does not need to add parameter meaning since none exist.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly uses the verb 'Fetch' to indicate the action, specifies the resource as 'Pavan's live GitHub profile statistics', and lists concrete data points (repos, followers, contributions). It distinguishes itself from siblings like get_github_activity by focusing on aggregate profile stats rather than activity streams.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus siblings (e.g., get_github_activity for recent activity). There are no exclusions, prerequisites, or hints about appropriate contexts. The description assumes the agent knows when to fetch profile statistics.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_profile_summaryA

Get a comprehensive one-page summary of Pavan Madduri's professional profile. Ideal for AI agents that need a quick overview.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full burden but only states it returns a summary. It does not disclose data freshness, caching behavior, authentication requirements, or what exactly the summary includes (e.g., skills, experience).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences that front-load the core action and provide a use case. No unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

While the tool has no parameters and an output schema exists, the description lacks detail on the summary's content areas (e.g., education, work history). It is adequate but could be more complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters, so the schema coverage is 100%. The description adds no parameter meaning, but baseline for zero-parameter tools is 4, and no further information is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool retrieves a comprehensive one-page summary of a specific person's profile, distinguishing it from sibling tools that focus on evidence, expertise, or GitHub data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'Ideal for AI agents that need a quick overview' implies usage context but does not explicitly specify when not to use this tool or provide alternative tool names for more detailed queries.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_articlesB

Search Pavan's published industry articles by keyword, category, or publication.

ParametersJSON Schema

Name	Required	Description	Default
`keyword`	Yes	Keyword to search in article titles, categories, or publications (e.g. 'AI', 'kubernetes', 'gitops', 'SRE', 'platform', 'argocd', 'zero-trust', 'dragonfly', 'CNCF', 'IEEE')

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations exist, but the description accurately characterizes the tool as a read-only search. However, it lacks details on pagination, result limits, or any behavioral traits beyond the basic search function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence, but it includes inaccurate information about searchable fields (category, publication) not supported by the schema, making it ineffective despite brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description does not cover output format or results structure despite an output schema existing. Combined with the parameter inaccuracy, the description is incomplete for a tool with one required parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has only one parameter 'keyword' with full description, yet the tool description claims search by 'category, or publication' which are not represented in the schema. This contradiction misleads about available filter options.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool searches Pavan's published industry articles with specific verb 'Search' and resource 'articles', and distinguishes from sibling tools like get_eb1a_evidence or get_github_activity which deal with different content types.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for finding articles but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. The purpose is clear but no comparative context is given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_contributionsB

Search Pavan's open source contributions by project name.

ParametersJSON Schema

Name	Required	Description	Default
`project`	Yes	Project name to search for (e.g. 'dragonfly', 'volcano', 'keda', 'opencolorio', 'kubernetes', 'tikv', 'opencue', etc.)

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.4/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, and the description does not disclose any behavioral traits (e.g., read-only, rate limits, side effects). For a search tool, read-only is implied but not explicit, leaving room for ambiguity.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence with no wasted words. It is front-loaded with the verb and resource, making it easy to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simplicity of the tool (one parameter, output schema available), the description is sufficient. It could mention the return format, but the output schema presumably covers that. The description is complete enough for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a description for the 'project' parameter that includes example values. The tool description adds no additional semantics beyond what the schema provides, so a baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'search' and the resource 'Pavan's open source contributions' with a specific filter 'by project name'. It distinguishes from sibling tools like get_github_activity or search_articles by focusing on contributions rather than general activity or articles.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided on when to use this tool versus alternatives. There is no mention of context, prerequisites, or when not to use it. Users must infer usage from the description alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

7 tool updatesv1.0.0Jun 15, 2026
- First observedget_eb1a_evidence
- First observedget_expertise
- First observedget_github_activity
- First observedget_github_stats
- First observedget_profile_summary
- First observedsearch_articles
- First observedsearch_contributions

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored 2026-06-15 00:55 across 7 tools

Disambiguation5/5

Each tool targets a distinct aspect: EB-1A evidence, expertise check, GitHub activity vs. stats, profile summary, article search, and contribution search. No functional overlap.

Naming Consistency5/5

All tools follow a consistent 'verb_noun' pattern in snake_case: get_* for retrieval and search_* for searching. No mixing of conventions.

Tool Count5/5

Seven tools cover the personal knowledge domain without being excessive. Each tool serves a clear purpose, and the count feels well-scoped.

Completeness4/5

Covers key areas (evidence, expertise, GitHub, articles, contributions) but lacks direct access to a 'projects' or 'skills' list. The profile summary partly compensates, but minor gaps exist.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
238
UnifAPIOAuth
com.unifapi
Hosted MCP server for live public-data APIs and Skills for AI agents.
Open Data Search AI & Machine Learning
2
saidsef-mcp-github-pr-issue-analyser
ai.smithery
A Model Context Protocol (MCP) application for automated GitHub PR analysis and issue management.…
Version Control Developer Tools Project Management
26
saagarpatel.dev Portfolio A
io.github.saagpatel
Agent-native MCP server over the public saagarpatel.dev corpus. Read-only, stateless.
Search Documentation Access
82

Related MCP Servers

resume-mcp
Knowledge & Memory
brysontang
F
license
Not graded
quality
C
maintenance
An MCP server that provides a structured API for AI agents to query a person's resume, including profile, projects, writing, and gated access to experience and skills.
Updated 2 months ago (2026-07-27 19:12 UTC)
-
GitHub MCP Server
aviralkaushik412
F
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that connects Claude AI directly to the GitHub API, enabling natural language queries for live repository data, issues, PRs, and contributions.
Updated 6 months ago (2026-03-19 03:56 UTC)
1
-
personal-context
Developer Tools Knowledge & Memory
Ayush7614
A
license
Not graded
quality
C
maintenance
Aggregates your digital footprint (GitHub, blogs, resume) into a single AI-readable profile and exposes it via MCP tools so AI agents can query your context live.
Updated 3 months ago (2026-06-18 20:23 UTC)
1
MIT
personal-resume-agent
RAG Systems Search
vsiwach
A
license
Not graded
quality
D
maintenance
Exposes a personalized AI agent that reads your resume and provides intelligent responses about your professional background through a standardized MCP server interface with RAG capabilities.
Updated a year ago (2025-09-25 13:20 UTC)
MIT