Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Portfolio MCP Server search portfolio for machine learning"
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.
A dual-stack Model Context Protocol (MCP) server for Srikanth Karthikeyan's portfolio data, available in both Node.js and Python implementations with containerized deployment options.
The server provides the following tools:
search_portfolioSearch through portfolio data by keywords, category, or content.
Parameters:
query (required): Search query to find relevant information
category (optional): Filter by specific category
limit (optional): Maximum results to return (default: 10)
get_portfolio_categoriesGet all available categories in the portfolio data.
get_portfolio_itemGet a specific portfolio item by ID.
Parameters:
id (required): The ID of the portfolio item
get_contact_infoGet all contact information.
get_tech_stackGet detailed information about technical skills and tools.
Parameters:
type (optional): Filter by specific tech type
Related MCP server: Bijon Portfolio MCP Server
# From npmjs.com (public)
npm install srikanth-mcp-portfolio-server
# From GitHub Packages
npm install @srikanth-karthi/srikanth-mcp-portfolio-server# From PyPI (public)
pip install srikanth-mcp-portfolio# Node.js version
docker run -it srikanthkarthi/mcp-portfolio-server:nodejs-latest
# Python version
docker run -it srikanthkarthi/mcp-portfolio-server:python-latest
# Multi-runtime version
docker run -it srikanthkarthi/mcp-portfolio-server:multi-latest# Node.js version
docker run -it ghcr.io/srikanth-karthi/mcp-portfolio-server:nodejs-latest
# Python version
docker run -it ghcr.io/srikanth-karthi/mcp-portfolio-server:python-latest
# Multi-runtime version
docker run -it ghcr.io/srikanth-karthi/mcp-portfolio-server:multi-latest# Choose one:
docker compose up mcp-portfolio-nodejs # Node.js only
docker compose up mcp-portfolio-python # Python only
docker compose up mcp-portfolio-multi # Both runtimesnpm install
npm run devpip install -e .
python -m mcp_portfolio_server.server{
"mcpServers": {
"portfolio": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"srikanthkarthi/mcp-portfolio-server:latest"
]
}
}
}{
"mcpServers": {
"portfolio": {
"command": "docker",
"args": [
"run",
"-i",
"--rm",
"ghcr.io/srikanthkarthi/mcp-portfolio-server:latest"
]
}
}
}{
"mcpServers": {
"portfolio": {
"command": "npx",
"args": ["srikanth-mcp-portfolio-server"]
}
}
}{
"mcpServers": {
"portfolio": {
"command": "npx",
"args": ["@srikanth-karthi/srikanth-mcp-portfolio-server"]
}
}
}{
"mcpServers": {
"portfolio": {
"command": "python",
"args": ["-m", "mcp_portfolio_server.server"]
}
}
}{
"mcpServers": {
"portfolio": {
"command": "node",
"args": ["/path/to/mcp-portfolio/src/index.js"],
"cwd": "/path/to/mcp-portfolio"
}
}
}The repository includes automated CI/CD workflows:
Triggers: Git tags (v*) or manual workflow dispatch
Builds: Multi-architecture Docker images (AMD64/ARM64)
Publishes:
Node.js package to GitHub Packages
Python package to PyPI
Docker images to GitHub Container Registry
# Build Node.js image
docker build --target nodejs -t mcp-portfolio:nodejs .
# Build Python image
docker build --target python -t mcp-portfolio:python .
# Build multi-runtime image
docker build --target multi -t mcp-portfolio:multi .Environment Variable | Description | Default |
| Node.js environment |
|
| Python output buffering |
|
| Portfolio data file path |
|
Switch between Node.js and Python in multi-runtime container:
# In docker-compose.yml, uncomment to use Python:
command: ["python3", "-m", "mcp_portfolio_server.server"]The server provides access to the following portfolio categories:
Profile Summary: Overview and introduction
Current Position: Job title, company, duration
Current Work: Responsibilities and projects
Experience: Work history and achievements
Education: Academic background
Tech Stack: Programming languages, frameworks, tools
Certifications: Professional certifications
Volunteerism: Community service and activities
Contact: Social media and professional links
Languages: Language proficiency
Search for cloud experience: search_portfolio("cloud", "Experience")
Get all tech stack info: get_tech_stack()
Find contact information: get_contact_info()
Search for certifications: search_portfolio("aws certification")
MIT
Get all contact information for Srikanth
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it mostly restates the tool's name. It does not specify whether it is read-only beyond the verb 'Get', what exactly 'all contact information' includes, or how results are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no filler or redundancy. It front-loads the action and resource effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimally adequate for a simple zero-parameter getter, but it omits details such as output format, usage scenarios, and any limitations. Given no annotations or output schema, more context would help the agent understand exactly what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the input schema carries no burden and the baseline for zero-parameter tools is 4. The description's phrase 'all contact information' adds some informational context but there is no parameter to elaborate on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action 'Get' and the resource 'all contact information for Srikanth', clearly distinguishing it from the portfolio-related sibling tools. It is unambiguous about what the tool returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. There is no mention of context, prerequisites, or any exclusion such as 'use this only when you need contact details'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all available categories in the portfolio data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It clearly indicates a read operation via 'Get', but adds no further context such as return format, ordering, or side effects. This is adequate but not rich, matching a minimal viable score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and to the point, earning a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (no parameters, no output schema), the description fully captures its purpose and behavior. It is complete for a simple list-returning tool and does not require additional explanation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100% by vacuity. The description adds no parameter-level detail, but none is needed. With 0 params, the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the resource 'all available categories in the portfolio data', clearly stating the tool's function. This distinguishes it from siblings like get_portfolio_item or get_tech_stack, which target different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage—when you need all categories—but does not explicitly discuss alternatives or when not to use it. Given the sibling tools, there is no clear comparison guidance, but the intent is understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific portfolio item by ID
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ID of the portfolio item to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for disclosing behavior. It only states that the tool gets an item by ID, with no mention of return format, error handling, rate limits, permissions, or whether the operation is read-only (though 'Get' implies it). The description adds minimal behavioral context beyond the tool's basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. Every word contributes meaning, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with one well-documented parameter, the description provides enough to invoke the tool correctly. However, with no output schema, the description does not explain what a portfolio item contains or what the response looks like, and it omits error behavior. It is minimally complete but leaves gaps in expected output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the 'id' parameter (type number, description 'The ID of the portfolio item to retrieve'), so schema coverage is 100%. The description adds nothing beyond 'by ID', which does not enhance the parameter's meaning. Baseline 3 is appropriate since the schema carries the semantic load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get a specific portfolio item by ID' with a specific verb and resource, and the 'by ID' qualifier distinguishes it from sibling tools like search_portfolio, which implies finding items without an ID. This is precise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you have a known portfolio item ID, but it does not explicitly state when to use this tool versus alternatives like search_portfolio. There is no mention of prerequisites, exclusions, or comparison to sibling tools, so the guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about Srikanth's technical skills and tools
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by specific tech type (e.g., "Programming Languages", "Cloud Platforms") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It merely states the purpose and does not mention return format, filters, read-only nature, authentication, or any other behavior. This is a significant gap for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that conveys the tool's purpose without any waste. It is front-loaded and efficient, achieving maximum clarity with minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description tells what it does but does not specify the return format or the optional 'type' filter, which is only in the schema. It is minimally adequate but lacks richer context that an output schema or extra detail would provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single optional parameter 'type', with a clear example. The description adds no additional meaning beyond the schema, so the baseline of 3 applies. The parameter is self-explanatory and the schema description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves detailed information about Srikanth's technical skills and tools. The verb 'Get' and the resource 'technical skills and tools' are specific, and it is clearly distinct from sibling tools focused on portfolio and contact info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusions. The agent must infer that this tool is for tech stack inquiries based on the name and siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search through Srikanth's portfolio data by keywords, category, or content
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return (default: 10) | |
| query | Yes | Search query to find relevant portfolio information | |
| category | No | Filter by specific category (e.g., "Tech Stack", "Experience", "Education") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the search action, offering no information about match behavior (e.g., partial vs exact), case sensitivity, output format, or ordering. This is insufficient for an agent to predict tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that directly states the core function. It avoids any filler or repetition, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the schema is detailed, the description lacks crucial context such as what specific data is searchable, what 'content' means, and what the response format will be. The presence of sibling tools helps infer the overall domain, but the description alone does not fully prepare an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters, so the description adds minimal extra meaning. It does map 'keywords, category, or content' to query and category, which provides a slight semantic bridge. The limit parameter is self-explanatory from its schema default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Search') and resource ('Srikanth's portfolio data'), plus the search dimensions ('keywords, category, or content'). This distinguishes it from sibling tools like get_portfolio_item or get_portfolio_categories, which imply direct retrieval rather than search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching when the exact item is unknown, but it does not explicitly contrast with sibling tools. There are no when-to-use or when-not-to-use guidelines provided, so the agent must infer from the tool name and context that this is for broad searches, not specific lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.5.0get_contact_infoget_portfolio_categoriesget_portfolio_itemget_tech_stacksearch_portfolioEach tool targets a distinct purpose: search_portfolio is for free-form discovery, get_portfolio_categories and get_portfolio_item handle browsing by category or ID, while get_contact_info and get_tech_stack provide specific static information. There is no meaningful overlap that would confuse an agent.
Most tools follow the 'get_' verb pattern, but search_portfolio deviates by using 'search_' instead. The two get_portfolio_* tools share a clear prefix, and the remaining get_* tools are still predictable and consistent in style.
With 5 tools, the server is well-scoped for a personal portfolio. Each tool serves a distinct and necessary function without redundancy or excessive granularity, making the set feel curated and complete for its purpose.
The read-only portfolio surface is well covered: search, category listing, item retrieval, contact information, and tech stack. A minor gap is the lack of an explicit 'list all items' operation, though search_portfolio may fill that role depending on implementation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Query professional profiles, search candidates, and get AI-powered summaries and job fit analysis.
Akshay Shetty's engineering portfolio and resume, queryable by AI. OAuth-secured.
An interactive portfolio built for AI conversations. Browse work, services, and book calls.
Turn a resume into a portfolio website, look up published profiles, and ask about Skillfolio.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/srikanth-karthi/mcp-portfolio'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
