Kannada/English Carnatic flute KSGMS syllabus — search lessons, log practice, ask a RAG guru.
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.
Average 3.7/5 across 7 of 7 tools scored. Lowest: 2.9/5.
Each tool serves a clearly distinct purpose: ask_venuvidya for Q&A, get_lesson and list_lessons for lesson content, get_class and list_classes for class journals, log_practice_session for practice tracking, and search_syllabus for keyword search. No overlapping functionality.
All tools follow a consistent verb_noun naming pattern using snake_case: ask_, get_, list_, log_, search_. The pattern clearly indicates action and target, making it predictable.
With 7 tools, the server is well-scoped for a study guide. It covers the core needs of querying content, viewing lessons and classes, logging practice, and searching without extraneous tools.
The tool set covers the main workflows: browsing lessons/classes, asking questions, searching, and logging practice. Minor gaps exist, such as no update/delete for practice logs, but these are not essential for the study guide purpose.
ask_venuvidyaAInspectAsk VenuVidya — the in-app RAG chatbot. Returns a grounded answer + citations.
Args:
question: Student question (2-1500 chars).
level: Optional level filter for retrieval ('junior' | 'senior' | 'vidwat').
language: 'en', 'kn' or 'auto'.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| language | No | auto | |
| question | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must compensate. It states the tool returns grounded answers with citations, but does not detail read-only nature, authentication requirements, or behavior under failure (e.g., no good answer). Some traits are implied but not explicit.
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 plus an Arg list. Front-loaded with purpose. Every sentence adds value, no waste. 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?
With no output schema, the description should detail return structure (beyond 'grounded answer + citations'). Missing info on error responses, pagination if any, or behavior for empty results. Context signals show 3 params, 1 required, but description covers them adequately. Could be more 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 0%, so description adds crucial constraints: question character limit (2-1500), level filter (junior/senior/vidwat), and language options (en, kn, auto). These go beyond the schema which only names parameters. Still missing expected value constraints for level (null or string) and language defaults.
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 uses specific verb 'Ask' and resource 'VenuVidya' (the in-app RAG chatbot), clearly distinct from sibling tools that deal with classes, lessons, practice, and syllabus.
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?
Tool's purpose as a Q&A chatbot is clear, and sibling tools cover different domains, so when to use it is implicitly understood. However, no explicit when-not-to-use or alternative suggestions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_classCInspectFetch a single class journal entry with its items and practice log.
| Name | Required | Description | Default |
|---|---|---|---|
| class_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states basic function. It does not disclose auth needs, error handling (e.g., invalid class_id), or whether the operation is read-only. Agent lacks behavioral insight beyond 'fetch'.
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 filler, front-loaded with verb and resource. Every word serves a purpose; no unnecessary detail.
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 having only one parameter and no output schema, the description does not define what 'class journal entry', 'items', or 'practice log' mean. Missing context needed for correct invocation and interpretation of results.
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 0%, and the description adds no meaning for the 'class_id' parameter. No format, constraints, or examples are provided, leaving the agent to infer from the name alone.
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 ('Fetch'), resource ('single class journal entry'), and included sub-resources ('items and practice log'). It effectively distinguishes from sibling tools like 'list_classes' (multiple) and 'get_lesson' (different resource).
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 (e.g., when to use 'list_classes' instead). Lacks any contextual information about prerequisites or scenarios, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_lessonAInspectFetch the full study content of a single lesson.
Args:
lesson_id: Lesson identifier, e.g. 'junior-theory-1-4'.
| Name | Required | Description | Default |
|---|---|---|---|
| lesson_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Fetch', implying a safe read operation, but omits details like output format, expected size, or any side effects.
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 short sentences, no wasted words. Parameter documentation is integrated clearly. Efficient for a simple tool.
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?
Adequate for a simple fetch: explains what it does and the parameter. However, no output schema or mention of return content, which may leave agents guessing about the 'full study content' structure.
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 0%, so description must compensate. It explains 'lesson_id' with an example 'e.g. 'junior-theory-1-4'', adding useful context beyond the schema property name.
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 'Fetch' and the resource 'full study content of a single lesson'. It distinguishes from siblings like 'list_lessons' (which lists multiple) and 'get_class' (different resource).
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 purpose is clear—use to get full content of one lesson—but there is no explicit guidance on when to avoid it or comparison with alternatives (e.g., 'list_lessons' for overview).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_classesAInspectList recent class journal entries (date descending).
Args:
level: optional level filter.
limit: max number of classes (1-100, default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read operation (list) and specifies ordering (date descending). No annotations provided, so the description must carry the full burden; it adequately discloses basic behavior but lacks details on edge cases or return format.
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 with essential information. The main action is front-loaded, and every sentence contributes meaning.
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 list tool with two parameters and no output schema, the description covers ordering, parameter constraints, and basic behavior. It could mention the return format or pagination, 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 coverage is 0%, so the description adds meaning: 'level' is an optional filter, 'limit' sets max results (1-100) with a default of 20. This clarifies parameter usage beyond the schema's type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists recent class journal entries in descending date order. The verb 'list' and resource 'class journal entries' are specific, and the tool is distinct from sibling tools like 'get_class' which retrieves a single entry.
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 such as 'get_class' or 'list_lessons'. Does not specify context or requirements for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_lessonsAInspectList lesson metadata. Filter by level/category.
Args:
level: 'junior' | 'senior' | 'vidwat'.
category: e.g. 'theory-1', 'practical-1', etc.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| category | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must disclose behavioral traits. It states the operation (list, filter) but omits return format (e.g., what 'metadata' includes), pagination, rate limits, or side effects. This is insufficient for a listing tool with no output schema.
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 concise (two sentences plus args list) and front-loaded with purpose. No wasted words; structured cleanly with args in a bullet-like format.
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, no output schema, and sibling tools, the description lacks completeness. It does not specify default behavior (e.g., what happens with no filters), return structure, ordering, or pagination, which are critical for a listing 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 description coverage is 0%, but the description provides possible values for 'level' and an example for 'category', adding meaning beyond the schema. It compensates well for the lack of 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?
Description uses specific verb 'List' and resource 'lesson metadata', and mentions filtering by level/category. This clearly distinguishes it from siblings like get_lesson (single lesson) and list_classes (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing/filtering lessons but does not explicitly state when to prefer this over siblings like get_lesson or search_syllabus. No direct comparison or exclusion criteria provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
log_practice_sessionAInspectLog a practice session against a class item. Requires admin_pin.
Args:
class_id: Parent class id.
item_id: Item id inside the class (kriti/varna/etc.).
practiced_on: Date in YYYY-MM-DD.
duration_min: Duration in minutes.
notes: Free-text notes.
rating: Self-rating 1-5.
admin_pin: Admin PIN required for writes.
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | ||
| rating | No | ||
| item_id | Yes | ||
| class_id | Yes | ||
| admin_pin | No | ||
| duration_min | No | ||
| practiced_on | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It reveals the admin_pin requirement, but fails to disclose other behavioral traits such as success/failure modes, idempotency, or side effects beyond logging.
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 concise, starting with a clear one-line purpose followed by a bullet list of parameters. It avoids unnecessary words, though the structure could be improved by grouping required parameters or highlighting the auth requirement more prominently.
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 tool with 7 parameters and no output schema, the description covers parameter semantics and the admin_pin requirement. However, it lacks information about return values, error handling, or confirmation, leaving some gaps in 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?
The description adds significant meaning to each parameter beyond the schema, which has 0% description coverage. It explains each argument's purpose (e.g., 'class_id: Parent class id.'), making it easier for an agent to map values correctly.
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 action 'Log a practice session against a class item.' It uses a specific verb and resource, distinguishing it from sibling tools that are primarily read or query operations.
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 mentions the requirement of admin_pin, giving a usage condition. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide context on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_syllabusAInspectKeyword (BM25) search across all Carnatic flute lessons.
Args:
query: Natural-language question or keywords (English or Kannada).
k: Number of top results to return (1-10, default 4).
level: Optional filter — 'junior', 'senior' or 'vidwat'.
| Name | Required | Description | Default |
|---|---|---|---|
| k | No | ||
| level | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the search algorithm (BM25) and parameters. It does not explicitly state side effects or read-only nature, but for a search tool this is reasonably transparent. The mention of BM25 adds behavioral detail.
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 clear sentence followed by a structured parameter list. Every sentence adds value, and the key information is front-loaded. No wasted words.
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 low complexity, no output schema, and no annotations, the description covers the core functionality and parameter usage. It lacks details about output format or ordering, but for a simple search tool with k results it is adequately 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 description coverage is 0%, and the description compensates fully by explaining each parameter: query as natural-language query, k as number of results (1-10, default 4), and level as optional filter with specific values (junior, senior, vidwat). This adds significant meaning beyond the schema.
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's a 'Keyword (BM25) search across all Carnatic flute lessons', which is a specific verb and resource. It distinguishes from sibling tools like get_lesson (individual retrieval) and ask_venuvidya (likely Q&A).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching across lessons but does not explicitly state when to use versus alternatives (e.g., ask_venuvidya for questions, list_lessons for overview). No when-not or alternative guidance is provided.
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.
No comments yet. Be the first to start the discussion!