Aula MCP Server

by ilenhart

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.2
Disambiguation5/5
Each tool targets a clearly distinct resource or action: auth status, login initiation, auth polling, daily overview, posts, messages, threads, calendar, gallery, people search, MeeBook, and attachment handling. Even the three auth-related tools are well separated by their specific roles.
Naming Consistency4/5
All tools share the 'aula_' prefix and snake_case format, with most following the verb_noun pattern (get_posts, get_thread, find_people). Minor deviations like 'aula_login' and 'aula_session_status' break the pattern slightly, but the overall style is consistent and readable.
Tool Count5/5
14 tools is well within the ideal range for a domain-specific server. Each tool covers a distinct feature of the Aula platform, from authentication to content retrieval, without unnecessary redundancy or bloat.
Completeness3/5
The server provides comprehensive read-only coverage for Aula: authentication, daily overview, posts, messages, threads, calendar, gallery, people, MeeBook, and attachments. However, it lacks any write operations (e.g., sending messages or creating posts) and does not explicitly address multiple children, leaving notable gaps for a full parent-facing integration.
Average 3.9/5 across 14 of 14 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 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
This repository is licensed under MIT License.
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?
With no annotations provided, the description must disclose behavioral traits. It only says 'Get', which implies a read operation, but does not mention any side effects, authentication needs, rate limits, or whether the response is paginated. The absence of any detail beyond the action leaves a transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the purpose without extraneous words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a simple schema with no output schema and no annotations. The description lists event types but does not explain return format, pagination, date range behavior, or when it is appropriate to use. It is minimally adequate but leaves gaps in context that could affect correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any parameter-specific meaning beyond what the schema already provides (e.g., filter enum, days_back/days_forward with defaults and bounds). No additional semantic value is contributed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose with a specific verb ('Get') and resource ('calendar events from Aula'), and enumerates event types (school events, excursions, holidays, lessons). It is not vague, but it does not explicitly differentiate from sibling tools like aula_get_daily_overview, which could overlap in scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention any exclusions, preferred contexts, or references to sibling tools, leaving the agent without direction for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It does not mention authentication needs, read-only nature, search behavior (e.g., partial matching, case sensitivity), or return value characteristics. It only states the subject and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 14 words, front-loaded with the verb 'Search', and contains no waste. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even for a simple two-parameter tool, the description omits details about return format, search behavior, and operational constraints. With no output schema and no annotations, this is insufficient for an agent to fully understand what happens upon invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with clear descriptions for both 'name' and 'role'. The tool description adds no extra parameter semantics, but the high schema coverage sets the baseline at 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Search for people'), specifies the resource ('people connected to your school on Aula'), and lists relevant categories (parents, children, teachers, employees). This clearly differentiates it from sibling tools that handle posts, messages, calendar, and auth.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, no exclusions, and no prerequisites are mentioned. The description merely states the tool's function; an agent must infer usage from sibling tool names alone.
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 are provided, so the description carries the full burden. It discloses that the response includes all messages, but it does not mention read-only nature, authentication, or return format. This adds some context but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that directly states the purpose without any waste. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter get tool, the description is adequate: it explains what is returned (full thread with all messages). However, there is no output schema and no explicit alternatives, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents thread_id with a description, and coverage is 100%. The tool description repeats the concept but does not add format or retrieval details, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets a full message thread by thread ID, including all messages. It uses a specific verb 'Get' and resource 'message thread', and the singular form distinguishes it from siblings like 'aula_get_threads' and 'aula_get_messages', though without explicit naming.
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 you have a thread ID and need the full conversation. However, it does not explicitly say when to use this over alternatives or provide exclusions, so guidance is only implied.
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 explicitly states the tool does not start an auth flow, which is a key behavioral trait. However, with no annotations, it does not disclose return values, side effects, or error conditions. The provided detail adds some transparency but is minimal.
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 entire description is a single concise sentence that directly states the tool's purpose without any filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description covers the basic purpose and one key behavior. However, it lacks return value information and does not clarify the difference from the sibling 'aula_check_auth', leaving some contextual gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description adds no parameter semantics. The baseline score of 4 applies because there is nothing to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Check' and identifies the resource 'current Aula session', clearly stating the tool's function. It adds 'without starting an auth flow' which partially distinguishes it from auth-flow tools, but it does not explicitly differentiate it from the sibling 'aula_check_auth'.
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 the tool is for checking session validity without triggering authentication, but it does not name alternatives or specify when to prefer this over 'aula_check_auth' or 'aula_login'. Usage context is inferred rather than explicit.
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?
With no annotations, the description must carry behavioral disclosure. It does convey a key trait: it does not return actual image data, only URLs. However, it omits details like authentication requirements, pagination behavior, or any side effects. This is moderate disclosure for a read-only fetch tool.
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?
Two short sentences, front-loaded with the main purpose and critical limitation. Every word earns its place, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no output schema and no annotations, so the description must explain return values. It states 'album metadata and media URLs' but 'album metadata' is vague, lacking fields or structure. Given the low complexity, the description is minimally complete but leaves room for clarification about the metadata contents.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with all three parameters having descriptions. The description itself adds no parameter-specific information, so it barely benefits above the schema baseline. It implicitly references time range via 'recent' but does not detail the parameters.
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 retrieves recent photo albums and media, and explicitly notes it returns metadata and URLs, not actual images. This specific verb+resource statement distinguishes it from sibling tools like get_posts or get_messages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (use when you need gallery/media information), but there is no explicit guidance on when not to use it or which alternative to prefer for actual image downloads. The note about returning URLs instead of images hints at using other tools, but no sibling tool is named.
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?
With no annotations, the description carries the transparency burden. It adds useful context (content is in Danish, messages are individual or group), but does not disclose authentication requirements, side effects, or behavior such as pagination, even though the schema hints at limit/days_back. This is adequate but incomplete.
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 two short sentences, front-loaded with the primary action ('Get recent messages') and free of redundant information. Every word adds value, and the language clarification is placed neatly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with two well-documented parameters and no output schema, the description adequately covers the core behavior, scope, and a key cultural detail (Danish content). It lacks explicit return format details, but given the tool's simplicity and the schema's completeness, it is sufficiently contextual for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with clear descriptions, defaults, and ranges for both parameters, so the baseline is 3. The description adds no extra meaning beyond what the schema already states, but it does provide the overall context of 'recent messages' that frames the parameter usage.
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 retrieves recent messages from Aula, specifying the type (individual or group) and source (teachers/parents). This distinguishes it from sibling tools like aula_get_posts or aula_get_threads, which target different content types.
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 recent messages are needed, but provides no explicit guidance on when to use this tool versus alternatives. No exclusions or alternative tool names are mentioned, so the agent must infer context from the sibling list.
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?
With no annotations, the description carries full burden. It adds that full message history is included, which is a useful behavior detail. However, it lacks information about potential large payloads, pagination, or any side effects. It's adequate but not rich.
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?
One sentence that is front-loaded with the main action and includes the key benefit ('full message history'). No wasted words.
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?
The description conveys what the tool returns and the filter concept. With no output schema, it would benefit from more detail on the response structure or potential limits, but for a simple read-only list tool with one parameter, it's reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (days_back is fully described). The description adds no extra parameter semantics beyond the schema, so baseline 3 is appropriate.
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 gets all message threads with recent activity and includes full message history. The verb 'Get' plus specific resource 'message threads' and scope 'recent activity' distinguishes it from sibling tools like aula_get_thread (singular) and aula_get_messages.
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 for listing active threads via 'recent activity' but doesn't explicitly name alternatives or exclusion criteria. There is no 'when not to use' guidance, but the context and sibling tool names indirectly suggest it's for bulk retrieval vs. single-thread access.
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 are provided, so the description carries the burden. It states the content is in Danish, a useful behavioral trait, and 'get' implies read-only, but it doesn't disclose pagination, sorting, or other behavioral details.
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 two sentences, front-loaded with the core purpose and a useful language note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list-retrieval tool with no output schema, the description conveys essential information: what is retrieved and the language of the content. It could describe the return structure, but the tool name and description make it reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover both parameters fully (100% coverage), so the description adds no additional parameter information. Baseline 3 applies.
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 retrieves recent general posts from Aula, specifying the content type as announcements and school updates. This distinguishes it from sibling tools like get_messages or get_threads.
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 implies the tool is for fetching general announcements and updates, providing clear context. However, it doesn't explicitly name alternative tools or provide when-not-to-use scenarios.
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 carries full burden. It adds valuable behavioral context, such as the possibility of receiving a refreshed QR screenshot if the previous one expired. This is beyond the empty schema and gives the agent useful expectations.
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?
Two concise sentences, front-loaded with the core purpose. Every word earns its place; no filler or 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?
For a zero-parameter, no-output-schema tool, the description covers the essential context: what it does, when to call it, and a possible edge-case output. It could mention the exact return format, but this is not critical for a simple status check.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is nothing for the description to explain. The baseline of 4 applies, and the description appropriately focuses on behavior rather than parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: checking if MitID QR code scan and authentication completed. It uses a specific verb ('check') and resource, but it does not explicitly distinguish this from the sibling tool 'aula_session_status'.
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?
Explicitly instructs to call after 'aula_login', providing clear timing context. It does not mention alternatives or when not to use, but the 'after login' guideline is practical and direct.
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 carries the full burden. It discloses the key behavioral trait of returning no file content to avoid context bloat, and notes the local save side effect, which is valuable context for the agent.
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 two sentences, front-loaded with the primary action, and the second sentence adds critical output behavior without any fluff or 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?
For a tool with no output schema, the description adequately summarizes the return (metadata and local path) and input source, though it could further elaborate on error handling or file naming edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides complete descriptions for all parameters (100% coverage). The description adds minimal value beyond schema, only reinforcing the URL source already mentioned in 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 downloads and saves an attachment locally, and explicitly distinguishes its output behavior (metadata and path, no content) from siblings like aula_view_attachment.
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?
It provides clear context on how to obtain the attachment URL (from aula_get_posts or aula_get_messages) and when to use it (to download/save), but does not explicitly exclude alternatives such as aula_view_attachment.
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 are provided, so the description must carry the full burden. It states what the tool returns but does not disclose authentication requirements, read-only nature, or any error conditions. As a simple getter, it is adequate but not rich, scoring a 3.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence contains all key information with no wasted words. The description is concise, front-loaded, and easily understood.
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 low complexity (zero params, no output schema), the description provides enough detail about the contents (lesson plans, goals, reading). It could mention the return format or potential absence of data, but for a simple getter it is essentially complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). The baseline for zero params is 4, and the description adds context about what is retrieved, which is sufficient without needing parameter details.
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 function: getting MeeBook weekly plans and book lists for a child's class. It specifies the resource (MeeBook) and the content (lesson plans, learning goals, reading), distinguishing it from sibling tools like daily overview or posts.
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 implies clear usage context (when you need weekly plans or reading assignments), but it does not explicitly mention when not to use it or alternatives. Since the purpose is obvious from the resource type, it earns a 4 for clear context without exclusions.
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?
With no annotations provided, the description must carry the burden of disclosure. It accurately indicates a read operation ('Get') and describes the returned content, but it does not mention authentication requirements, data freshness, timezone behavior, or any other potential side effects. Basic but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that directly states the action and the included items. It is concise without unnecessary words, and every word contributes meaning.
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?
For a tool with no parameters, no output schema, and no annotations, the description sufficiently covers what the tool does and what it returns. The low complexity means the description is complete enough for an agent to invoke it 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?
There are zero parameters, and schema coverage is 100% (trivially). The description doesn't need to compensate for parameter documentation. Baseline for zero-parameter tools is 4, and no additional parameter semantics are required.
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 function: retrieving today's daily overview for a child, listing the specific content (attendance, check-in/out times, notes). This uses a specific verb and resource, distinguishing it from sibling tools that handle posts, messages, calendar, etc.
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 phrase 'for your child' implies the intended use context (parent accessing child's daily overview), which is clear enough for selecting the tool. However, it does not explicitly state when not to use it or name alternative tools, so it misses the explicit exclusion guidance that would earn a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the tool's side effects: it may open a Chrome window, displays a MitID QR code, and returns a screenshot. This goes beyond a simple 'login' label by describing the interactive flow and the expected output, which is critical for an agent to know about the browser-launching behavior.
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 two sentences, with the primary verb and resource front-loaded in the first sentence. Every sentence adds meaningful behavioral detail, and there is no irrelevant or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is fairly complete: it explains the purpose, the conditional behavior (existing session vs. new authentication), and the output (screenshot). However, it does not mention what happens after the screenshot is scanned or how to confirm completion, leaving some uncertainty about the full workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema is empty. The description correctly avoids describing any parameters. Per the baseline rule for zero params, a score of 4 is appropriate; there is nothing more needed.
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: 'Start Aula authentication.' It also distinguishes itself from sibling tools like aula_session_status and aula_check_auth by describing the actual login initiation process (opening Chrome with a QR code) rather than just checking status.
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 context for when to use the tool: when authentication is needed or when you want to ensure a valid session. It also explains that it confirms existing sessions, which implies it can be used as a first step. However, it does not explicitly name alternative tools or state when to prefer a status-only check, so some guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries behavioral transparency. It discloses return format (base64/text), the 1MB MCP response limit, the ~750KB failure threshold, and fallback behavior for large files. This is rich operational context beyond the raw schema.
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?
Three focused sentences: primary action, explicit usage condition, and critical warning/fallback. No wasted words, front-loaded with the core purpose, and every sentence earns its place.
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?
For a 2-parameter tool with no output schema, the description covers return format, constraints, failure modes, and alternative action. It is complete enough for an agent to use correctly without further clarification.
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 100%, so the baseline is 3, but the description adds meaningful context: explains that local_path comes from a previous response and clarifies why max_size_mb defaults to 0.75MB to stay under the MCP limit. This adds value beyond the schema descriptions.
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 loads and views a previously downloaded attachment, returning file content as base64 or text. The phrase 'previously downloaded' distinguishes this from sibling aula_get_attachment, making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states 'ONLY call this when the user explicitly asks to view/see/analyze an attachment,' giving clear when-to-use guidance. It also provides a concrete alternative for large files (S3 URL or local file path), effectively stating when not to use the tool.
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:

[![aula-mcp-server MCP server](https://glama.ai/mcp/servers/ilenhart/aula-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/ilenhart/aula-mcp-server)

Score Badge

Copy to your README.md:

[![aula-mcp-server MCP server](https://glama.ai/mcp/servers/ilenhart/aula-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/ilenhart/aula-mcp-server)

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/ilenhart/aula-mcp-server'

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