Professor Fit MCP

by Wrennnn2

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose within the professor discovery and management workflow. The descriptions are detailed and prevent confusion between similar tools like search_professors (coarse filter) and find_professors (full pipeline).
Naming Consistency4/5
Most tools follow a verb_noun pattern (e.g., find_professors, update_professor_profile), but profiles_export and profiles_inspect use a noun_verb pattern, creating a minor inconsistency.
Tool Count5/5
Nine tools cover the essential operations for professor profiling and ranking without unnecessary complexity. The count is well-scoped for the domain.
Completeness4/5
The tool set covers the core workflow of searching, fetching details, ranking, adding evidence, updating, inspecting, and exporting. Missing explicit create/delete tools, but the workflow implicitly supports creation through evidence merging.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 18 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. The description does not disclose behavioral traits such as side effects, permissions, rate limits, or error conditions. It only describes parameters and return shape, leaving the agent uninformed about operational behavior.
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 well-structured with clear Args and Returns sections, and the main purpose is front-loaded. While it is longer than necessary, every sentence provides useful information, and there is no redundancy.
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 high parameter count and no output schema, the description covers all parameters and the return shape. It references a sibling tool for further detail. However, missing behavioral transparency and explicit usage guidelines prevent a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates thoroughly. Each parameter is explained with meaningful context (e.g., 'topic_keywords: Core topic terms (high scoring weight)', 'regions: Country/region codes. Supported: US, UK/GB, JP...'). This adds substantial value beyond the schema titles.
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 'Search for professors matching research interests (coarse filter).' This provides a specific verb ('search'), resource ('professors'), and a qualifying scope ('coarse filter'), effectively distinguishing it from the sibling 'find_professors' tool.
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 hints at an alternative tool by referencing 'See find_professors' for topic_keywords, and the phrase 'coarse filter' suggests this is for broader queries. However, it does not explicitly state when to use this tool versus find_professors or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses deterministic whole-word keyword matching and separates server-side and client-side responsibilities. However, it lacks details on potential limitations, error handling, or behaviors like what happens with no matches. Without annotations, more transparency would be beneficial.
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 somewhat lengthy but well-structured with sections for server-side, client-side, args, and returns. Each sentence serves a purpose, though some repetition could be trimmed. It balances detail with readability.
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 complexity (4 parameters, nested objects, no output schema, no annotations), the description is quite complete. It covers input formats, output structure, and usage flow. Missing some edge cases like default filters behavior, but overall adequate.
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 carries the burden. It explains user_interests format in detail (including optional fields like preset, description, paper_urls, weighting) and briefly mentions filters and sort_by options. This adds significant value beyond the schema's generic 'object' type.
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 ranks professors by keyword overlap and packages materials for client LLM fit judgment. The verb 'rank' and resource 'professors by keyword overlap' is specific and distinguishes it from sibling tools like find_professors or search_professors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the input professors should come from search_professors or get_professor_details, and instructs the client to use fit_materials for judgment. It does not explicitly mention when not to use this tool, but provides clear context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It describes output format but does not mention if it modifies data, requires permissions, or other safety considerations.
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?
Structured with Args and Returns sections, concise, every sentence adds value with no fluff.
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?
Complete for a formatting tool: explains inputs, outputs (dict with content/format/saved_to), and ties to rank_fit. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description fully explains each parameter: professors (from rank_fit), format (options + default), include_summary (default), output_path (optional). Adds meaning beyond schema.
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?
Description clearly states 'Export ranked professors as a formatted table' with a specific verb and resource. It ties input to rank_fit, distinguishing it from siblings like profiles_export.
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?
Implied usage from description (requires rank_fit output), but no explicit guidance on when to use this tool vs siblings like profiles_export or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses behavior: fetches multiple sources, includes source/confidence metadata, and provides homepage_search_query if homepage_url is null. However, it omits error handling 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a clear summary first, then bullet-like details for each argument and return values. It is concise enough but every sentence serves a purpose. Minor room for improvement in brevity.
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 3 parameters (none required) and no output schema, the description covers inputs thoroughly and explains the output fields including edge cases. It is complete for a tool of this complexity.
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%, but the description compensates well by explaining each parameter: professor_id is the preferred OpenAlex ID, name is used if ID is missing, and university aids disambiguation. This adds value beyond the schema.
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's purpose: 'Get detailed multi-source profile for a professor.' It specifies the sources (OpenAlex, DBLP, homepage) and key data points, making it distinct from sibling tools like 'search_professors' which likely performs broader searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use the tool (to get a detailed profile) and the parameter usage (preferred professor_id, fallback name+university). It does not explicitly exclude cases or name alternatives, but the context implies it for detailed profiles vs. broader searches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behaviors: it explains parameter effects (e.g., omitting output_path returns inline content, include_evidence only for JSON) and describes the return dict. It doesn't cover side effects or auth but overall provides good transparency.
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 well-structured with a one-line summary, then Args and Returns sections. Every sentence is necessary and front-loaded with the main purpose. No redundant information.
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 no output schema, the description provides a return value structure (dict with content, format, total, saved_to). It covers parameter details and behavior. It lacks error handling or concurrency notes, but for a simple export tool it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by detailing each parameter: format's allowed values (json/markdown/csv), output_path behavior, and include_evidence constraint. This adds meaning beyond the schema's types and defaults.
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 'Export professor profiles from the local database', using a specific verb and resource. This purpose distinguishes it from siblings like 'find_professors' or 'export_table'.
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 when exporting professor profile data but does not explicitly state when to use this tool over alternatives or provide exclusions. No explicit when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It explains that the tool returns data (stats, summaries, full profile) with no indication of side effects, making its read-only nature clear. No destructive behavior mentioned, which is appropriate.
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 well-structured with clear sections, front-loading the overall purpose then detailing arguments. It is reasonably concise without being overly verbose.
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 5 parameters and no output schema, the description explains the return format (dict with stats/profiles/profile+evidence) and covers all arguments. It lacks details on pagination or sorting, but for a local inspection tool this is sufficient.
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%, but the description details all 5 parameters with their effects (partial name match, filter by institution, etc.), adding meaning beyond the bare schema types and defaults.
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's purpose: inspect the local professor profiles database. It distinguishes three modes (stats, filtered summaries, full profile with evidence) which differentiates it from sibling tools like find_professors or get_professor_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use each parameter: no arguments for stats, filters for summaries, openalex_id for full profile. It does not explicitly contrast with siblings, but the context of alternatives is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It states that only provided fields are updated (others unchanged) and describes the return format (dict with success and message). This is fairly transparent, though it lacks details on error conditions or whether the professor must already exist.
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 well-structured: a purpose sentence, usage guidance, a tagged Args list, and a Returns line. It is concise enough to be quickly parsed, though the Args list could be slightly more compact by grouping related parameters.
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 12 parameters, no output schema, and no annotations, the description is highly complete. It explains all parameters, the patch-like update behavior, usage context, and return format. It covers what an agent needs to invoke 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?
Schema description coverage is 0%, so the description must compensate. It lists all 12 parameters with brief explanations and examples (e.g., position as 'Assistant Professor', verification_status as 'verified'|'needs_review'|'unverified'). This adds meaning beyond the bare schema, though examples are minimal.
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 'Manually update fields on a professor profile in the local profiles database.' This specifies the action (update) and resource (professor profile), distinguishing it from sibling tools like get_professor_details or find_professors that read or search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using this tool for writing confirmed fields (homepage URLs, positions, etc.), which provides clear usage context. However, it does not explicitly state when not to use this tool or mention alternatives beyond the implicit list of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of explaining behavior. It describes that extracted fields are 'stored as evidence' and optionally 'merged into the professor's profile with cross-source verification.' It also mentions the return format. However, it does not detail failure modes, permissions required, or the exact nature of 'cross-source verification.' Still, it provides sufficient transparency for an additive operation.
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 concise: one purpose sentence, one usage guideline sentence, a bulleted Args list, and a return description. Every sentence adds value. The Args list is well-organized but not overly verbose. No redundant information. It is efficiently structured and easy to scan.
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 tool's complexity (8 parameters, nested object, no output schema), the description covers inputs and output comprehensively. It explains the return dict keys (evidence_id, merged, verification_status). However, it lacks explanation of error cases, rate limits, or potential side effects (e.g., whether merging is reversible). For a tool that modifies professor profiles, this omission slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate fully. It does so by listing each parameter with its purpose and allowed values: e.g., 'source_type: One of: faculty_page, personal_homepage...', and for extracted, 'Supported keys: homepage_url, name, institution...' It also specifies defaults for optional parameters like confidence and auto_merge. This adds substantial meaning beyond the raw schema.
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's primary action: 'Add WebSearch evidence for a professor and optionally merge it into their profile.' It provides a specific verb ('Add') and resource ('WebSearch evidence'), and distinguishes from sibling tools like 'update_professor_profile' which update profiles without an evidence step. The purpose is unambiguous and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool: 'Call this after using web search to find a professor's faculty page or personal homepage.' This provides clear context for invocation. However, it does not explicitly mention when not to use it or list alternative tools for similar tasks, though no sibling tool performs the same evidence-adding function. The guidance is useful but could be more comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden. It details the pipeline steps: search, concurrent multi-source detail fetching, relevance ranking, and Markdown table rendering. It also explains keyword weighting and scoring. It doesn't cover rate limits or auth, but overall it's transparent.
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 long but well-structured with a clear summary, a highlighted important section, and a bulleted args list. It front-loads the purpose and key instructions. Minor redundancy could be trimmed, but it's well-organized.
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 12 parameters and no output schema, the description is very complete. It explains the full pipeline, return value structure (including keys like markdown, ranked_professors, total), and important constraints like concurrent fetching and auto-analysis fallback.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description extensively explains every parameter, especially the most critical ones (topic_keywords, domain_keywords, weights). It provides usage examples and clarifies the role of each parameter, far beyond the schema property titles.
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 this is a 'One-shot professor finder (RECOMMENDED entry point)' and explains it runs a full pipeline including search, concurrent fetch, ranking, and Markdown rendering. It distinguishes itself from siblings like search_professors by being the comprehensive entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent guidance on how to split keywords into topic vs domain for precise results, including examples. It also explains fallback behavior if only keywords are given. While it doesn't explicitly say when not to use it or directly compare to siblings, the guidance is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![ProfessorFitMCP MCP server](https://glama.ai/mcp/servers/Wrennnn2/ProfessorFitMCP/badges/card.svg)](https://glama.ai/mcp/servers/Wrennnn2/ProfessorFitMCP)

Score Badge

Copy to your README.md:

[![ProfessorFitMCP MCP server](https://glama.ai/mcp/servers/Wrennnn2/ProfessorFitMCP/badges/score.svg)](https://glama.ai/mcp/servers/Wrennnn2/ProfessorFitMCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Wrennnn2/ProfessorFitMCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server