StudiePoint AI
Server Details
Scholarship database, GPA converter, visa guidance, and cost estimator for African postgraduate students. 172 full-ride + 61 full-tuition scholarships across 32 countries, 54 nationalities, 13 grading systems. 6 tools. No auth required.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 6 of 6 tools scored.
Each tool serves a distinct function: visa checking, GPA conversion, cost estimation, specific scholarship details, personalized matching, and general search. There is no overlap in purpose, and the descriptions clearly differentiate them.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_visa, convert_gpa, match_scholarships). The verbs are informative and the nouns are domain-specific, making the pattern predictable.
With 6 tools covering the core needs of a study-abroad planning service, the count is well-scoped. Each tool earns its place without being overwhelming or insufficient.
The tool set covers the main workflow: visa info, GPA conversion, cost estimation, and scholarship discovery/detail/match. Missing features like profile management or application tracking are minor gaps, but the core is solid.
Available Tools
6 toolscheck_visaAInspect
Check the visa accessibility rating for an African student of a given nationality applying to study in a specific destination country. Returns a rating (green = easy, yellow = moderate, red = difficult/restricted), notes on the visa process, and any important restrictions.
| Name | Required | Description | Default |
|---|---|---|---|
| destination | Yes | Destination country. Examples: 'UK', 'Germany', 'USA', 'Canada', 'Australia', 'France', 'Netherlands', 'Sweden', 'Norway', 'Japan', 'China', 'South Korea', 'Italy', 'Austria', 'Portugal'. | |
| nationality | Yes | The student's nationality. Examples: 'Nigerian', 'Kenyan', 'Ghanaian', 'South African', 'Ethiopian', 'Tanzanian', 'Ugandan', 'Rwandan', 'Senegalese', 'Moroccan', 'Egyptian', 'Zambian', 'Zimbabwean', 'Cameroonian'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the output (rating, notes, restrictions) but does not disclose potential delays, data freshness, or any side effects. However, as a read-only lookup, the information is adequate.
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, well-structured sentence that front-loads the purpose and includes all essential information without redundancy.
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 covers the tool's purpose, inputs, and output (rating, notes, restrictions) adequately for a simple lookup tool with no output schema. It could be slightly more detailed about the rating system or potential edge cases, but overall it is sufficient.
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?
Schema description coverage is 100%, so baseline is 3. The description adds context (African student, study) but does not provide additional details beyond the schema for the two parameters (nationality, destination).
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 verb ('Check'), the resource ('visa accessibility rating'), and the specific context ('African student', 'study in a specific destination country'). It distinguishes this tool from sibling tools (e.g., convert_gpa, get_scholarship) by specifying its unique function.
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 the tool is for checking visa ratings for African students, but it does not explicitly state when to use it versus alternatives or when not to use it. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_gpaAInspect
Convert a grade from any of 13 African grading systems to the international 4.0 GPA scale used by scholarship applications worldwide. Covers all 54 African countries. Also returns the grade class (e.g. 'First Class Honors') and how the GPA is interpreted in Germany, UK, France, USA/Canada, Australia, Netherlands, and Japan/Korea/China.
| Name | Required | Description | Default |
|---|---|---|---|
| grade | Yes | The grade class or value. For class-based systems use: 'first_class', 'second_upper', 'second_lower', 'third_class', 'pass'. For kenyan letter grades: 'A', 'B+', 'B', 'C+', 'C', 'D'. For percentage systems: '75%', '68', etc. For french_20: 'tres_bien', 'bien', 'assez_bien', 'passable'. For spanish_10: 'matricula', 'notable', 'aprobado'. | |
| scale | Yes | Grading system. nigerian=5.0 scale, kenyan/ghanaian/ethiopian/west_african_4=letter/class, south_african=percentage, tanzanian/ugandan=5.0 class, zimbabwean/rwandan/percentage=%, french_20=20-point (26 Francophone+Lusophone countries), spanish_10=10-point (Equatorial Guinea). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description fully discloses behavior: conversion, coverage of all 54 African countries, 13 systems, and additional return of grade class and international interpretations. No contradictions.
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?
Two sentences, front-loaded with purpose. Could be more structured but is efficient and contains no fluff.
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 no output schema, description explains output includes grade class and international interpretations. Parameters are fully covered. Tool is simple, description is complete.
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?
Schema coverage is 100%. Description adds significant value by providing detailed examples and mapping for grade values and scale enum, far beyond schema's brief descriptions.
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 converts African grading systems to international 4.0 GPA scale, with specific verb 'Convert' and resource 'grade'. It distinguishes from siblings which are visa/cost/scholarship related.
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?
Describes when to use (converting African grades) but does not explicitly state when not to use or alternative tools. However, siblings are unrelated, so context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
estimate_study_costsAInspect
Estimate and compare the total annual cost of studying in one or more countries for an African postgraduate student. Covers 32 destinations: Tier 3 affordable EU (Germany, France, Italy, Austria, Portugal, Poland, Czech Republic, Estonia, Baltic states, Balkans), Tier 2 full-tuition scholarship countries (Netherlands, Belgium, Scandinavian countries, Japan, South Korea, Switzerland), and benchmark high-cost countries (UK, USA, Canada, Australia). Returns annual cost breakdown: tuition, living, flights, health insurance, visa fee, and total. Use scholarship_mode=true to show the self-funding gap when tuition is already covered by a scholarship.
| Name | Required | Description | Default |
|---|---|---|---|
| lifestyle | No | Budget = shared accommodation, public transport, cooking at home. Comfortable = private room, occasional dining out. Default: budget. | |
| degree_level | No | Degree level. Default: masters. | |
| destinations | No | List of country IDs or names to compare. IDs: germany, france, italy, austria, portugal, poland, czech_republic, estonia, latvia, lithuania, romania, slovakia, croatia, hungary, slovenia, bulgaria, greece, netherlands, belgium, ireland, denmark, finland, sweden, norway, switzerland, japan, south_korea, hong_kong, uk, usa, canada, australia. Alternatively use common names: 'Germany', 'UK', 'United States', etc. Leave empty to return all destinations. | |
| scholarship_mode | No | If true, sets tuition to €0 (assuming tuition is covered by scholarship) and shows only living costs, flights, insurance, and visa. Useful for comparing cities when a student already has a tuition scholarship. Default: false. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what the tool returns (cost breakdown with tuition, living, flights, etc.) but omits details like data sources, update frequency, or assumptions. Since no annotations are provided, the description carries full burden, and while it discloses output structure, it lacks deeper behavioral context.
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 5 sentences, front-loaded with the main purpose. It efficiently covers scope, target audience, special mode, and output structure without any redundant or irrelevant information.
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 no annotations and no output schema, the description is quite complete. It covers purpose, usage, special mode, and return details. The only minor gap is the behavior when 'destinations' is empty (returns all), which is implied but not explicit.
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?
All 4 parameters have schema descriptions covering defaults and values (100% coverage). The tool description adds value by explaining scholarship_mode's purpose and the return breakdown, which complements the schema. This goes beyond what the input schema alone provides.
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 verb ('estimate and compare'), the resource ('total annual cost of studying'), and specifies the target user ('African postgraduate student') and scope (32 destinations). It distinguishes well from sibling tools like check_visa or convert_gpa, which address entirely different needs.
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 explains when to use scholarship_mode, which is a key usage hint. However, it does not explicitly state when not to use this tool or provide alternatives. Given that sibling tools are unrelated, the absence of a negative guideline is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_scholarshipAInspect
Get complete details on a specific scholarship by name or keyword search. Returns: full name, host country, scholarship amount, deadline, minimum GPA, essay type, acceptance rate, visa accessibility, partner universities, application URL, and committee values.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Scholarship name or search keyword. Examples: 'Chevening', 'DAAD', 'Rhodes', 'Fulbright', 'Gates Cambridge', 'Commonwealth', 'Erasmus Mundus', 'MasterCard Foundation', 'Aga Khan', 'Australia Awards', 'MEXT', 'Korea GKS', 'Eiffel'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It clearly indicates this is a read-only lookup operation returning specific fields. It does not mention side effects, authentication requirements, or error behavior, but for a simple retrieval tool, the description is sufficient.
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 two sentences: purpose and a bullet-like list of return fields. It is front-loaded, contains no redundancy, and every sentence provides value.
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 simplicity (one parameter, no output schema, no annotations), the description covers the key aspects: what input to provide and what output to expect. It lacks details on edge cases (e.g., no match found) but is largely complete for typical use.
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?
Schema coverage is 100%. The description restates the parameter purpose ('by name or keyword search') but does not add new semantics beyond the schema's property description. It lists return fields but that relates to output, not parameter semantics.
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 purpose: 'Get complete details on a specific scholarship by name or keyword search.' It lists the exact fields returned, which distinguishes it from sibling tools like search_scholarships (which likely returns summaries) or match_scholarships (which likely filters based on criteria).
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 when to use this tool (when you need full details of a known scholarship) and implicitly contrasts with sibling tools that handle visa, GPA, costs, or matching. However, it does not explicitly state when not to use it or mention alternative tools by name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
match_scholarshipsAInspect
Get personalised, ranked scholarship recommendations for an African student based on their full profile. Uses StudiePoint's matching algorithm to score scholarships by GPA fit, field alignment, visa accessibility, deadline urgency, and acceptance rate. Returns top matches with match score, reasoning, and direct application links.
| Name | Required | Description | Default |
|---|---|---|---|
| field | Yes | Student's field of study. | |
| limit | No | Number of top matches to return. Default 5, max 15. | |
| nationality | Yes | Student's nationality (used for visa scoring). | |
| degree_level | No | Degree level sought. | |
| converted_gpa | Yes | Student's GPA already converted to the 4.0 scale. Use convert_gpa first if needed. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It describes the matching algorithm and return values, but does not disclose whether the tool is read-only or has side effects. The description adequately covers input-output but lacks explicit safety or idempotency notes.
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?
Three concise sentences, front-loaded with the main purpose, no redundant information. Every sentence adds value.
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 no output schema, the description explains the return format (top matches with score, reasoning, links). Input parameters are fully specified in schema. Missing details on pagination or error handling, but not critical for this tool.
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?
Schema coverage is 100%, so baseline is 3. The description adds context about how parameters are used in the algorithm (e.g., GPA fit, visa accessibility) but does not add significant detail beyond the schema descriptions.
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 purpose: providing personalized, ranked scholarship recommendations for African students. It names the algorithm and key scoring factors, and distinguishes from siblings like search_scholarships by emphasizing personalization and ranking.
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 this tool is for personalized matching based on a full profile, but does not explicitly state when to use it over siblings like search_scholarships or convert_gpa. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_scholarshipsAInspect
Search StudiePoint's database of 210 full-ride scholarships and 100 full-tuition scholarships for African postgraduate students. Filter by destination country, field of study, minimum GPA (4.0 scale), degree level, and tier. Returns scholarship name, country, amount, deadline, minimum GPA, essay type, visa accessibility, and application URL.
| Name | Required | Description | Default |
|---|---|---|---|
| tier | No | 'full_ride' = fully funded (tuition + living + flights). 'full_tuition' = tuition only, student funds living. 'affordable_eu' = low/no-tuition EU universities across 17 countries. | |
| field | No | Field of study. Examples: 'engineering', 'medicine', 'business', 'law', 'sciences', 'arts', 'agriculture', 'public health', 'economics', 'computer science'. | |
| country | No | Destination country. Examples: 'UK', 'Germany', 'USA', 'Canada', 'Australia', 'Netherlands', 'France', 'Japan', 'China', 'South Korea', 'Sweden', 'Norway'. | |
| min_gpa | No | Maximum minimum GPA required (4.0 scale). Only return scholarships the student can qualify for. | |
| degree_level | No | Degree level: 'masters' or 'phd'. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the search behavior (read-only) and the returned fields. It does not mention any destructive side effects, which is appropriate. The description is transparent enough for a search tool, though it could note any authentication requirements.
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?
Two sentences: first states the action and scope, second lists filters and return fields. Every sentence is essential, front-loaded, and free of redundancy. Highly efficient.
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?
Despite no output schema, the description enumerates all return fields (name, country, amount, deadline, etc.) and mentions the database size, target population, and filter options. This provides sufficient context for an agent to understand what the tool returns and how to use it.
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?
Schema coverage is 100% with each parameter described. The description echoes the filter categories but adds no additional meaning beyond what the schema already provides. Since schema carries the full semantic load, the description adds marginal value, meeting the baseline for high coverage.
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 defines the tool as searching a specific database of 210 full-ride and 100 full-tuition scholarships for African postgraduate students, with explicit filtering criteria. This distinguishes it from siblings like 'get_scholarship' (retrieve a specific one) and 'match_scholarships' (matching algorithm).
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 specifies the target audience (African postgraduate students) and the database scope, providing clear context for when to use this tool. However, it does not explicitly state when not to use it or name alternatives, though sibling names imply differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!