storefront
Server Details
US college admissions fit (College Scorecard bands) + verified admitted-student mentor search.
- 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/5 across 5 of 5 tools scored. Lowest: 3.4/5.
Each tool serves a distinct purpose: fit assessment, lead capture, booking options, university listing, and mentor search. There is no overlap in functionality, allowing an agent to clearly distinguish which tool to use for each task.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., assess_admissions_fit, capture_lead, get_booking_options). This makes the tool set predictable and easy to navigate.
With 5 tools, the server is well-scoped for its storefront purpose. Each tool addresses a core user need (fit assessment, lead capture, booking, university info, mentor search) without unnecessary bloat or insufficiency.
The tool set covers key storefront operations: assessing fit, listing universities, searching mentors, capturing leads, and providing booking options. One minor gap is the lack of a direct booking or session management tool, but the external booking link mitigates this.
Available Tools
5 toolsassess_admissions_fit입시 적합도 진단ARead-onlyInspect
학생의 시험 점수(SAT/ACT)와 목표 대학 목록을 받아, College Scorecard 실데이터 기반으로 학교별 REACH/MATCH/SAFETY 적합도를 분류합니다. 합격 확률 예측이 아닌 밴드 분류이며, 근거(점수 밴드·합격률)를 함께 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| act | No | ACT 총점 | |
| sat | No | SAT 총점 | |
| target_universities | Yes | 목표 대학 이름 목록 (영문/한글/약칭 허용, 예: MIT, Harvard) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true and openWorldHint=false. The description adds behavioral context: it uses real data, is a band classification not prediction, and returns evidence. 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?
The description is two sentences, concise and front-loaded with the core action, input, and output. Every sentence is necessary.
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 description covers the main functionality, it lacks explicit output structure documentation. With no output schema, more detail on the returned fields would improve completeness.
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 parameter descriptions. The tool description does not add significant meaning beyond the schema, providing only a baseline 3.
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 takes test scores and target universities, classifies into REACH/MATCH/SAFETY bands using College Scorecard data, and returns evidence. It distinguishes itself from probability prediction and sibling tools.
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 explicit when-to-use or when-not-to-use guidance is provided. While sibling tools are not similar, the description does not offer context for selecting this tool over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
capture_lead상담 연락처 저장AIdempotentInspect
상담을 이어가고 싶은 사용자의 연락처를 저장합니다. 사용자가 명시적으로 연락받기를 원할 때만 호출하세요. 호출 전 반드시 개인정보 수집 고지를 사용자에게 전달하고 동의를 받으세요 — 개인정보 수집·이용 안내 — 목적: 입시 상담 연락. 수집 항목: 이메일(및 사용자가 직접 제공한 관심사). 보관 기간: 목적 달성 또는 삭제 요청 시까지. 귀하는 동의를 거부할 권리가 있으며, 미동의 시 연락 안내가 제한될 수 있습니다. 자세한 내용: https://goanywhere.guru/privacy 저장 후 온보딩 링크를 안내합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | 사용자 이메일 (본인 동의 필수). 형식 오류 시 안내 메시지로 재질문됩니다. | ||
| interest | No | 관심사 요약 (예: 'SAT 과외 + MIT 지원 전략') | |
| student_profile | No | 사용자가 대화에서 제공한 프로필 요약 (선택) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint=true. Description adds valuable behavioral context: consent requirement, privacy notice, and post-action (onboarding link guidance). No contradiction with 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 well-structured with the core purpose first, followed by critical consent instruction and privacy details. While slightly lengthy due to legal text, it is necessary and well-organized.
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 3 parameters (1 required) and no output schema, the description covers the main behavior, consent requirement, and post-save onboarding. It sufficiently prepares the agent for correct invocation.
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%; all parameters have descriptions. The tool description adds minimal extra semantic value beyond the schema, merely noting the post-save action. Baseline 3 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 clearly states the verb '저장합니다' (saves) and the resource '연락처' (contact info of users wanting counseling). It distinguishes from sibling tools like 'assess_admissions_fit' or 'search_mentors' which serve different purposes.
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?
Explicitly instructs to call only when the user explicitly wants to be contacted, and includes a privacy consent notice. While it doesn't list alternative tools for non-consent scenarios, the guidance is clear and contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_booking_options예약 옵션 조회ARead-onlyInspect
특정 멘토의 세션 옵션(15/30/60분)과 가격, 예약 딥링크를 반환합니다. 예약·결제는 goanywhere.guru 사이트에서 진행됩니다 (이 도구는 링크 안내까지만).
| Name | Required | Description | Default |
|---|---|---|---|
| mentor_id | Yes | search_mentors 가 반환한 mentor_id |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, confirming read-only behavior. The description adds valuable context that the tool only returns a link and does not handle booking or payment, which is beyond the annotation's scope.
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 concise sentences with no wasted words. The first sentence states the output, the second clarifies the tool's limitation. Ideal length for quick comprehension.
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 lookup tool with one parameter and no output schema, the description is fully complete. It explains the scope, the external website, and the limitation of only providing a link.
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% for the single parameter mentor_id. The description adds value by linking the parameter to the output of search_mentors, providing semantic context beyond the schema definition.
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 it returns session options (15/30/60 min), price, and booking deep link for a specific mentor. It explicitly distinguishes itself by noting it only provides the link, not actual booking/payment, which differentiates it from sibling tools like search_mentors and capture_lead.
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 after selecting a mentor from search_mentors, but lacks explicit when-not or alternative guidance. However, the purpose is clear enough for the agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_supported_universities지원 대학 목록BRead-onlyInspect
적합도 진단이 지원되는 대학 목록과 각 대학의 합격률·SAT/ACT 밴드(College Scorecard 실데이터)를 반환합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| country | No | 국가 코드 (예: US) |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so description adds value by noting data source (College Scorecard real data). But lacks details on auth, rate limits, or handling of invalid country codes.
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?
Single sentence, no wasted words, front-loaded with purpose and key return fields.
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 read-only tool with one optional parameter, description is fairly complete. However, it does not clarify behavior when country is omitted (likely returns all universities).
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% for the only parameter 'country'. Description does not add extra parameter meaning beyond what the schema already 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?
Description clearly states it returns a list of supported universities with acceptance rates and SAT/ACT bands from College Scorecard. However, it does not differentiate from sibling tools like assess_admissions_fit.
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 on when to use this tool versus alternatives. Agent must infer context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_mentors멘토 검색ARead-onlyInspect
GoAnywhere의 승인된 합격생 멘토를 검색합니다. 실제 등록된 멘토만 반환하며(가상의 멘토 없음), 각 멘토의 학교·전공·합격 이력·평점·프로필 링크를 제공합니다.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No | 학교/전공 키워드 | |
| region | No | 입학 지역 (예: USA, UK) | |
| subject | No | 담당 과목 (과외) | |
| position | No | 포지션: consultant(입시 컨설턴트) | tutor(과외) | |
| major_field | No | 전공 계열 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations show readOnlyHint=true and openWorldHint=false, indicating safe read. Description adds that only real (not virtual) mentors are returned and specifies the data provided, which is valuable context beyond 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?
Two sentences, minimal waste. The first sentence front-loads the core purpose. Every word earns its place.
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 parameter count (6) and no output schema, the description explains the return fields sufficiently. It covers the essentials for a search tool, though pagination or error handling details are absent.
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?
With 83% schema description coverage, the schema already documents most parameters. The description does not add extra meaning for individual parameters beyond what the schema provides. Baseline 3 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 clearly states it searches for GoAnywhere's approved mentors, distinguishes by emphasizing real mentors only, and lists the returned fields (school, major, admission history, rating, profile link). This distinguishes it from siblings like assess_admissions_fit or capture_lead.
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 does not explicitly state when to use this tool versus alternatives like assess_admissions_fit or list_supported_universities. It only implies usage for searching mentors, but no guidance on when not to use or exclusions.
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!