How do I use ask-habib-mcp?

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., "@ask-habib-mcp What has Habib Ur Rehman published on deepfake detection?" 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.

ask-habib-mcp

by habib-analyst

Overview Schema Source Related Servers Discussions Admin

Python

Local

ask-habib-mcp

License: MIT Python 3.10+

An MCP (Model Context Protocol) server that exposes Habib Ur Rehman's professional profile — five 2025 publications and a CV summary — as tools and a resource that any MCP client (Claude Desktop, a website chat-widget backend, an agent) can query.

The problem

Recruiters and collaborators ask chatbots about Habib and get hallucinations: invented papers, wrong venues, phantom affiliations. This server is a small, grounded, citable source of truth. A chatbot with ask-habib-mcp connected answers "what did Habib publish on deepfakes?" from the actual corpus instead of making something up.

Related MCP server: portfolio-mcp

Architecture

MCP client (Claude Desktop / chat-widget backend / agent)
        │   JSON-RPC 2.0
        ▼
   stdio transport
        │
        ▼
  askhabib.server  (MCPServer, package: askhabib)
   ├─ tools: list_publications, get_publication,
   │         search_publications, get_profile, get_links
   └─ resources: profile://habib/cv   (Markdown CV)
        │
        ▼
  askhabib.data   (ground-truth corpus — titles, venues, years;
                   summaries flagged draft: True)
        │
   no network calls, ever

The corpus lives in-process (askhabib/data.py); every tool call is a local function call wrapped as an MCP tool. Nothing leaves the machine.

Quickstart (< 5 minutes)

git clone https://github.com/habib-analyst/ask-habib-mcp
cd ask-habib-mcp
pip install -r requirements.txt
pip install .

# sanity check — runs a real stdio MCP session against the server
python -m askhabib.demo_client

Claude Desktop

Add to your Claude Desktop config (claude_desktop_config.json):

{
  "mcpServers": {
    "ask-habib": {
      "command": "ask-habib-server",
      "args": []
    }
  }
}

If you installed without the console script, use the fallback instead:

{
  "mcpServers": {
    "ask-habib": {
      "command": "python",
      "args": ["-m", "askhabib.server"]
    }
  }
}

Restart Claude Desktop, then ask: "What has Habib Ur Rehman published on federated learning?"

Example session

Real transcript, captured from python -m askhabib.demo_client against the stdio server:

>>> client: starting ask-habib MCP server over stdio
<<< server: hello — ask-habib (protocol 2025-11-25)
<<< server: tools available: list_publications, get_publication, search_publications, get_profile, get_links
>>> client: search_publications(query="deepfake")
<<< server: 1 match(es):
    - Multimodal-FNet: Unparametrized Token Mixing for Multimodal Deepfake Detection
    (summaries are drafts pending his verification)
>>> client: get_publication(publication_id="p1")
<<< server: Revolutionizing medical imaging: A cutting-edge AI framework with vision transformers and perceiver IO for multi-disease diagnosis
    Computational Biology and Chemistry, 2025 (published)
    summary: Hybrid framework combining Vision Transformers with Perceiver IO for multi-disease diagnosis across imaging domains including MRI, CT/X-ray, and dermoscopic images. Evaluated on Stroke, Alzheimer's, Tinea, Melanoma, Pneumonia, and Lung Cancer cases. Ships with
... [truncated]
>>> client: get_profile()
<<< server: Habib Ur Rehman — ML/AI Engineer
    ML/AI Engineer at SANWA SYSTEM SERVICE CO. LTD
    BS Data Analytics, Government College University Faisalabad (2021-2025)
    skills: Python, PyTorch, TensorFlow, Hugging Face, LangChain/LangGraph, ...
>>> client: read_resource('profile://habib/cv')
<<< server: Markdown CV (3890 chars), opens with: '# Habib Ur Rehman'
>>> client: session closed

Honest note: draft summaries

Titles, venues, and years in this corpus are exact. The 2–3 sentence summary on each paper is a draft written from the title and venue description, pending verification by Habib himself — every record carries "draft": true, every full-record response includes a summary_note, and the server instructs connected clients to say so when quoting a summary. Treat summaries as a starting point, not as his words.

Tools & resources

Name	Type	What it returns
`list_publications`	tool	id / title / venue / year for all 5 papers (JSON)
`get_publication`	tool	full record for one id (`p1`…`p5`); clean error for unknown ids (JSON)
`search_publications`	tool	keyword search over titles + summaries + venues (JSON)
`get_profile`	tool	CV summary: bio, role, education, skills, interests, contact (JSON)
`get_links`	tool	GitHub, LinkedIn, website, email (JSON)
`profile://habib/cv`	resource	the profile rendered as Markdown

Roadmap

Replace draft summaries with Habib-verified text (draft: false)
Add arXiv/DOI/publisher links per paper
Wire into the habib.top "Chat with Habib" widget backend
Optional: publication/talk resources beyond the static corpus

Spec

Built against the Model Context Protocol specification using the official mcp Python SDK (stdio transport).

License

Available Tools

5 tools

get_linksA

Return contact links: GitHub, LinkedIn, website, email (JSON).

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

No annotations exist, so the description carries the full burden, and it only discloses that output is JSON with four named fields. It says nothing about authentication requirements, whether fields can be null/absent, or rate limiting, though the read-only, zero-parameter nature of the tool keeps the risk low.

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 short sentence that front-loads the verb and resource and then enumerates the payload. Nothing is wasted and nothing important is buried.

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?

With an output schema present and zero parameters, the description needn't explain return values further, so the remaining requirement is minimal. The '(JSON)' note and field list are slightly redundant with the output schema, but overall the definition is sufficient to call the tool correctly.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline applies. The enumerated field list does help set expectations about the returned link categories.

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

Purpose4/5

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

A specific verb ('Return') plus a specific resource ('contact links') with the returned fields enumerated (GitHub, LinkedIn, website, email). It is clearly distinguishable from the publication siblings, though it never contrasts with get_profile, which could plausibly also surface links.

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?

Usage is only implied by the returned content — an agent infers it should call this when it needs contact/social URLs. There is no explicit statement of when to prefer this over get_profile, and no conditions or prerequisites are given.

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

get_profileA

Return Habib Ur Rehman's CV summary: bio, current role, education, skills, research interests, and contact links (JSON).

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations, so the description carries the burden: it discloses that the payload is JSON and enumerates the fields, which is meaningful. It omits anything about currency/staticness of the CV data or whether the call has side effects, though a zero-parameter call is self-evidently a read.

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?

One front-loaded sentence with no filler, and the content list is the most useful part. Slight redundancy in restating the JSON payload that the output schema already defines.

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?

With an output schema present, the description need not explain return values, and it correctly signals the domain (bio, role, education, skills, contact links). The only gap is the unexplained boundary with get_links.

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 zero parameters, so there is nothing to disambiguate and the baseline of 4 applies. The description correctly does not invent inputs.

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

Purpose4/5

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

States a specific verb (Return) and resource (CV summary) and enumerates the contents, so an agent knows this is the personal-profile tool rather than a publications tool. It does not address the overlap with sibling get_links, which likely also surfaces contact links.

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?

Usage is only implied by the content list; there is no explicit when-to-use statement, no prerequisite, and no routing away from the sibling get_links for the contact-link portion. An agent can infer it is the entry-point 'about me' call, but must guess.

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

get_publicationA

Return the full record (title, venue, year, summary) for one publication id such as 'p3' (JSON).

Name	Required	Description	Default
`publication_id`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the behavioral burden. 'Return' strongly signals a read-only retrieval and it notes JSON output plus the fields returned, but it does not mention behavior for missing/invalid ids or any permission/error characteristics.

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 front-loaded sentence with no wasted text. It communicates the action, scope, example input, and output format efficiently.

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?

An output schema exists, so the description does not need to fully document return values, and it still names the main record fields. For a simple single-id getter, the main omission is error or not-found behavior.

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?

Schema description coverage is 0%, so the description must compensate for the single parameter. It does so by identifying the publication id and giving a concrete example ('p3'), though it does not specify id format rules or edge cases.

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 uses a specific verb ('Return') and resource ('full record') scoped to 'one publication id', and the singular phrasing distinguishes it from the list/search publication siblings. The example id ('p3') makes the input expectation concrete.

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 when to use it by saying it takes one publication id and returns the full record, which is useful context. However, it does not explicitly say when to prefer it over list_publications or search_publications or state exclusions.

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

list_publicationsA

List all publications as id/title/venue/year records (JSON).

Name	Required	Description	Default
No parameters

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the operation returns all publications as JSON records with specific fields, but it does not mention authentication, pagination, ordering, result size, or rate limits.

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 front-loaded sentence with no filler. It states the action, scope, output format, and record fields efficiently.

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 zero-parameter read-only listing tool with an output schema, the description is largely complete: it says what is returned and in what record shape. It could be stronger by stating whether results are paginated or ordered, but the output schema covers much of the return-value detail.

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?

This tool has zero parameters, so there are no parameter semantics to explain; the baseline is 4. The description correctly does not waste space describing nonexistent inputs.

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

Purpose4/5

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

The description states a specific verb and resource: it lists publications and specifies the returned record shape (id/title/venue/year as JSON). The word 'all' scopes it away from search_publications and get_publication, but it does not explicitly name those siblings.

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 use of 'all' implies this is the unfiltered listing tool, contrasting with search_publications and get_publication. However, it gives no explicit when-to-use guidance, no exclusions, and no alternative-tool routing.

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

search_publicationsA

Keyword-search publications over titles, summaries and venues (JSON). Example queries: 'deepfake', 'federated', 'vision transformer'.

Name	Required	Description	Default
`query`	Yes

Output Schema

Name	Required	Description
`result`	Yes

TDQS

A3.6/5.0

Behavior3/5

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

No annotations exist, so the description must carry the burden; it makes clear this is a read-oriented lookup over specific fields, but says nothing about matching semantics (substring vs. ranked), result limits, pagination, or empty-result behavior. An output schema exists, so return shape is partly covered elsewhere.

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?

Two short sentences, front-loaded with the search scope followed by examples; nothing is padding. The stray '(JSON)' tag is the only minor noise.

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?

With one parameter, an output schema handling return values, and no annotations, the description covers the essentials an agent needs to call it correctly. Only the lack of sibling differentiation and matching behavior keeps it short of full completeness.

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?

Schema coverage is 0% and the single parameter is only named 'query', but the description compensates by stating which fields are searched and supplying concrete example values, which is meaningful guidance beyond the bare schema.

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

Purpose4/5

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

The description names a specific verb (keyword-search) and resource (publications) and states the searched fields (titles, summaries, venues), so the purpose is unambiguous. It does not distinguish itself from the sibling list_publications, which an agent must disambiguate between.

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?

Example queries ('deepfake', 'federated', 'vision transformer') imply the tool is for topical lookup, but there is no explicit statement of when to use this versus list_publications or get_publication, and no exclusions or prerequisites.

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.

5 tool updatesv0.1.0Oct 28, 2026
- First observedget_links
- First observedget_profile
- First observedget_publication
- First observedlist_publications
- First observedsearch_publications

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.9/5.0

Scored 2026-10-28 23:00 across 5 tools

Disambiguation4/5

list_publications, get_publication, and search_publications have clearly distinct retrieval semantics (enumerate vs. fetch-by-id vs. keyword query), so an agent can pick correctly. The only soft overlap is get_profile vs. get_links, since get_profile's description already promises 'contact links' that get_links also returns.

Naming Consistency5/5

Every tool follows the same verb_noun snake_case pattern (list_/get_/search_ + resource). Resource nouns are used consistently and predictably across the set.

Tool Count5/5

Five tools is a tight, well-scoped surface for a personal publications/CV server; each tool covers a distinct access pattern and none appears redundant enough to remove.

Completeness4/5

The read-only domain (browse, fetch, search publications; profile and links) is fully covered with no dead ends. Minor gaps: no filtering/listing by venue or year, and get_links largely duplicates contact data already in get_profile.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Related MCP Connectors

ThothOAuth
io.github.ahmedEid1
Read-only MCP over an agentic SLR workspace with per-claim citation verification
Research & Data Knowledge & Memory
22
https://thoth-slr.vercel.app/api/mcp/mcp
Atlas Research A
io.github.ahmedEid1
Read-only MCP over an agentic SLR workspace with per-claim citation verification
Research & Data Knowledge & Memory
22
https://atlas-sooty-delta.vercel.app/api/mcp/mcp
SciWeaveOAuth
io.github.desci-labs
AI research grounded in 300M scientific works — every citation a verifiable DOI.
Research & Data Search
2
https://mcp.sciweave.com/mcp
LivingMeta — AI in ResearchOAuth
ai.livingmeta
Read-only MCP over the LivingMeta AI-in-Research corpus: 12,400 papers, gaps, priority agenda.
Research & Data Search
2
https://ai-in-research.livingmeta.ai/mcp

Related MCP Servers

whoami-mcp
Developer Tools
Hemant-Agrawal
A
license
Not graded
quality
D
maintenance
Exposes a person's structured professional profile as MCP tools, enabling Claude and other MCP clients to answer questions about that person based on real data.
Updated 4 months ago (2026-06-28 12:23 UTC)
3 npm
1
MIT
portfolio-mcp
RAG Systems Search Documentation Access
ckc5800
F
license
Not graded
quality
B
maintenance
Enables AI assistants to query the author's career, projects, publications, and technical documents through read-only MCP tools.
Updated 10 days ago (2026-10-19 11:31 UTC)
-
Portfolio MCP
RAG Systems Search
aim-t
F
license
Not graded
quality
C
maintenance
Enables AI assistants to query a person's CV and portfolio content via MCP tools and resources, returning grounded answers from local markdown data instead of relying on resume parsing.
Updated 2 months ago (2026-08-24 21:23 UTC)
-
mcpme
Knowledge & Memory Documentation Access
dheimgartner
F
license
A
quality
B
maintenance
Enables MCP-compatible agents to answer questions about you by exposing your CV through a tool, resource, and prompt.
Updated 2 months ago (2026-09-08 18:32 UTC)
1
-