IE Student MCP

by victor-gurbani

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
The three clear prefixes (ie_, connects_, blackboard_) and singular/plural resource naming make most tools easy to tell apart. The main ambiguity is between ie_login_status and ie_auth_status, which both concern sign-in state but with different scopes.
Naming Consistency4/5
Most tools follow a predictable domain_prefix + resource pattern, with plural/singular pairs like connects_events/connects_event and blackboard_courses/blackboard_course. A few verb-style exceptions such as ie_get_started and blackboard_download are minor deviations in an otherwise consistent scheme.
Tool Count2/5
At 34 tools, this exceeds the 25+ threshold and feels heavy even for a dual-platform student integration. While each tool has a defined purpose, the surface could be consolidated, especially around status checks and list/detail pairs.
Completeness4/5
The tool set provides broad read coverage across both Blackboard and Connects, including courses, content, grades, assessments, calendar, messages, discussions, attendance, events, groups, people, schedule, feed, rooms, resources, and chats. It is intentionally read-only, so missing write actions are not gaps; minor omissions like a dedicated assignments list or syllabus shortcut are workarounds.
Average 3.8/5 across 34 of 34 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on September 7, 2026
- 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, and non-destructive behavior. The description adds only 'personalized' and 'discovery recommendations', implying user-specific output, but does not disclose pagination, personalization details, or behavior when the view parameter is omitted. 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, and the core resource is front-loaded. The phrase 'dashboard or discovery recommendations' is slightly ambiguous, which prevents a perfect score.
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?
With one optional enum parameter, an output schema, and safety-related annotations, the description is mostly adequate for a simple tool. Still, it does not explain how the view parameter changes the response or when this dashboard tool should be preferred over sibling connects_* tools.
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 exposes a single optional 'view' parameter with a self-descriptive enum and default value. However, schema description coverage is 0%, and the description does not explain what each enum value returns or how 'discovery recommendations' maps to the available views.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource ('IE Connects dashboard or discovery recommendations') and mentions personalization, but it lacks an explicit verb such as 'returns' or 'fetches'. It also does not clearly distinguish this dashboard entry point from sibling tools like connects_feed or connects_activity.
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 about when to use this tool versus alternatives, such as connects_feed, connects_activity, or blackboard_dashboard. There are no conditions, alternative suggestions, or exclusion criteria beyond what can be inferred from the tool name.
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?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive behavior. The description adds a meaningful behavioral nuance: permission-denied authoring fields are not bypassed, which clarifies exactly what 'accessible' means. This goes beyond the annotation hints and helps set expectations for access control.
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 only two sentences with no redundant phrasing. The core purpose is front-loaded in the first sentence, and the second sentence adds a valuable caveat without unnecessary detail.
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 four parameters but the description omits any mention of pagination (limit/offset) or filtering by content_id, relying on conventional parameter names and an output schema. The permission caveat is helpful, but the missing parameter guidance and lack of usage direction leave the definition only minimally adequate for a 4-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the four parameters (course, content_id, limit, offset). An agent is left to infer that course is a contextual scope, content_id filters, and limit/offset paginate—none of which is explicitly stated. The description fails to compensate for the schema gap.
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 resource (assessments) and the operation (discover/read accessible metadata), which is specific enough to signal the domain. However, it does not explicitly contrast with sibling tools like blackboard_content or blackboard_grades, so the boundary is implied rather than stated with full clarity.
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?
There is no guidance on when to use this tool instead of related alternatives such as blackboard_content or blackboard_grades. The sentence about permission-denied fields is a limitation note, not a usage directive, leaving the agent without conditions or exclusions to select the right tool.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds 'Restricted sections remain unavailable', which is useful behavioral context beyond annotations. No contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise and front-loads the key resource and view options, then adds a useful caveat about restricted sections. It is appropriately sized for a read-only tool, though the list-like structure could be slightly clearer with an explicit verb.
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 four parameters, seven enum views, and existing annotations, the description covers the main purpose and a key restriction, but omits pagination semantics and does not explain the relationship between the view values and the parameters. The output schema helps, but the description alone is only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for undocumented parameters. It paraphrases the view enum values (details, roster/instructors, timetable, tools, progress) but does not name the 'view' parameter or explain 'limit', 'offset', or 'course'. This is only partial compensation for the schema gap.
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 indicates this tool provides details about a single course, including role, roster/instructors, timetable, tools, and progress. It distinguishes from the sibling blackboard_courses by focusing on a single course's detail views, though it does not explicitly say 'get a single course'.
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 when to use the tool: when you need course-level details such as roster, schedule, tools, or progress. It does not explicitly contrast with sibling tools like blackboard_courses or blackboard_content, nor does it state when not to use it, so guidance is only implicit.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is well-covered. The description adds useful exclusion context ('no joins, survey submissions or other writes') that matches and slightly extends the annotations. There is no contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loads the key verb 'Read', and avoids filler. The phrase 'one structured collection' is somewhat vague, and 'no joins' reads awkwardly, but overall it is an efficient, well-sized description.
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 output schema, enum values, defaults, and annotations fill many gaps, so the description does not need to explain return values or safety. Still, it lacks explicit guidance for choosing this tool over siblings and leaves parameter meanings to inference, making it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for this gap. It makes only an indirect reference to the 'view' parameter by mentioning 'about page or one structured collection', and gives no guidance on group_id, limit, offset, or query semantics.
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 a read action on a group resource ('Read a group's about page or one structured collection') and explicitly distinguishes it from write operations. It could be more precise by naming the available collection views or differentiating itself from connects_groups, but the core purpose is clear.
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 this tool is for read-only group data access and states what it does not do ('no joins, survey submissions or other writes'). However, it does not explicitly name alternative sibling tools or provide conditions for when to choose connects_groups, connects_events, or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint. The description adds meaningful behavioral context beyond annotations by emphasizing privacy and explicitly warning that an empty list is not proof of absence, which reinforces the open-world nature and informs interpretation of results.
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 extremely concise: two short sentences that front-load the core action and then add a critical interpretive caveat. Every word earns its place, with no redundant filler.
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?
With six optional parameters, no schema parameter descriptions, and many sibling tools, the description leaves important gaps: no guidance on how to filter, no mention of pagination behavior, and no routing to connects_person for retrieving an individual. The output schema helps with return values, but overall the description is incomplete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden for parameter understanding, but it mentions no parameters at all. The parameter names and types are somewhat self-explanatory, but the description does not clarify query semantics, how filters combine, or whether 'query' searches name/email/etc.
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 states a specific action ('Search the visible IE directory') and the resource is clear enough given the tool name 'connects_people'. It suggests a people-directory search and is distinguishable from singular siblings like connects_person, though it does not explicitly say 'people'.
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 explicit guidance is given about when to use this tool versus alternatives such as connects_person or other connects_* tools. The description implies a directory search but does not state exclusions or conditions for choosing a sibling.
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?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds a non-obvious behavioral caveat: some views return page metadata rather than complete structured records, and completion should not be inferred. This 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loads the primary purpose, and keeps the caveat short. There is no fluff, repetition, or redundant restatement of the tool name.
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 single parameter has an enum and default, annotations cover safety/open-world behavior, and an output schema exists, so the operational burden on the description is low. However, the description lacks any relational guidance among the many connects_* siblings and does not clarify which 'surfaces' correspond to which enum values, leaving moderate ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only vaguely frames the view parameter as 'activity surfaces.' It does not explain individual enum values such as transcript-layout, service-hours, or their default behavior, leaving the agent to guess what each view returns.
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 a clear verb ('Read') and a resource ('personal activity surfaces'), which is concrete enough to orient an agent. It does not explicitly differentiate from the many connects_* siblings, so it falls just short of a 5.
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 gives no guidance on when to use this tool versus connects_dashboard, connects_events, connects_feed, or the other sibling read tools. The only conditional language ('Some return page metadata...') is an output-interpretation warning, not a tool-selection guideline.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a meaningful behavioral detail beyond the annotations: reading does not mutate read state and does not post content. This is genuinely useful context for an 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 a single front-loaded sentence with no filler. Every phrase earns its place: the action, the resource scope, and the behavioral constraint are all present without redundancy.
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?
This tool has six parameters and a hierarchical discussion structure (forums → threads/messages → replies), but the description does not explain how the parameters work together to navigate that hierarchy. Despite having an output schema, an agent would likely struggle to know when to set forum_id versus message_id or how view changes the request scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. It mentions 'forums, threads and replies,' which loosely maps to the view enum, but it does not explain the relationship between course, view, forum_id, message_id, limit, or offset. The hierarchical navigation semantics remain unclear.
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 a specific verb ('Read') and a clear resource ('discussion forums, threads and replies'), and adds a scope qualifier ('without posting or mutating read state'). It is clear and directionally distinct from siblings like blackboard_messages, though it does not explicitly name any sibling for contrast.
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 this tool is for read-only access to discussion content, which gives a reasonable usage signal. However, it does not explicitly state when to choose this over alternatives such as blackboard_messages or other Blackboard tools, nor does it mention exclusions or prerequisites.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is well covered. The description adds valuable context beyond annotations by explicitly stating that it 'cannot send messages or change read state,' which clarifies the exact limitations for chat operations. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the primary purpose. It earns its place by stating both what the tool does and a key limitation. It could be slightly more detailed about parameter usage without becoming bloated, but as written it is highly efficient.
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 four parameters and an output schema, so return values need no explanation. However, the description is somewhat incomplete because it does not help the agent understand the 'view' enum choices or pagination semantics. The enum names like 'list', 'messages', 'files', and 'participants' are self-explanatory, and defaults/constraints in the schema fill some gaps, but richer guidance would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden of explaining parameters. However, the description mentions no parameters at all. While the schema provides enum values for 'view', defaults, and constraints for limit/offset/chat_id, the agent gets no additional semantic meaning from the description about how to choose a view or what chat_id should represent.
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 a specific action ('Read') on a specific resource ('existing chat data'). It effectively communicates that this tool is for retrieving chat data. While it doesn't explicitly differentiate from sibling tools, the 'chats' resource is distinct among the listed siblings.
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 reading chats by saying 'Read existing chat data' and clarifies that sending messages or changing read state is not possible. However, it provides no explicit guidance on when to prefer this tool over alternatives or when not to use it. The context is clear but exclusionary guidance is absent.
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?
The description adds valuable behavioral context beyond the annotations: it explains logical pagination, tells the agent to use next_offset, and clarifies that scan_exhausted signals an incomplete bounded search rather than an absence of results. This is especially useful given the openWorldHint annotation and helps the agent interpret pagination responses correctly.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with the core purpose in the first sentence and critical pagination semantics in the second. No filler is present, though the second sentence is dense with jargon that could be slightly clearer.
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?
Annotations and the output schema cover safety and return shape, and the description supplies important pagination semantics. However, with six input parameters and no schema descriptions, the tool definition leaves parameter meaning mostly to inference, and it does not help the agent choose this tool over event-related siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate for undocumented parameters, but it does not explain query, scope, category, group_id, limit, or offset. The phrase 'including your registered upcoming or past events' only indirectly hints at scope values like my-upcoming and my-past, and the mention of next_offset concerns an output field rather than an input parameter.
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 states a clear action ('Search/list') and resource ('events'), and adds scope context ('including your registered upcoming or past events'). It does not explicitly differentiate from sibling tools like connects_event or connects_schedule, but the plural 'events' and search/list framing make its broad listing purpose reasonably clear.
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 explicit guidance is provided about when to use this tool versus siblings such as connects_event, connects_schedule, or other event-related tools. The description implies a search/list use case but does not state exclusions or alternatives, leaving the agent to infer the correct selection.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable behavioral context by disclosing 'local pagination over at most 1,000 matches,' which is not inferable from the annotations or schema. This is a meaningful extra constraint.
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, efficient sentence that front-loads the core purpose and adds the most important behavioral caveat (pagination cap). No words are wasted.
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?
With five parameters, no schema descriptions, and an output schema present, the tool is mostly self-explanatory for a simple list/search operation. However, the lack of guidance on 'query' and 'category' semantics, and the absence of any alternative-routing notes, leaves moderate gaps for an agent trying to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of parameter explanations. It hints at 'mine' via 'your memberships' and at limit/offset via 'local pagination,' but it does not explain 'query' or 'category' semantics, which remain ambiguous despite the schema's type information.
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 states a clear action ('Find') and resource ('groups/clubs or your memberships'), and the plural name distinguishes it from the singular 'connects_group' sibling. It does not explicitly name the sibling alternative, but the scope is specific enough for an agent to understand the tool's role.
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 searching groups/clubs or listing memberships, but it does not explicitly state when to choose this tool over alternatives like connects_group or connects_people. There is no exclusion or comparison guidance, leaving the routing decision largely to inference.
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?
Annotations already establish readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description's 'Read' aligns with those. It adds useful scope information ('course or system announcements') and explains that supplying IDs returns detail. It does not describe pagination behavior or response ordering, but the safety profile is well covered by annotations.
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 with no filler. The primary action is front-loaded, and each clause adds distinct information: scope of the read and how to get details. Nothing is redundant with the schema or annotations.
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?
An output schema exists and annotations are rich, so the description does not need to explain return values or safety. For a low-complexity read tool, it covers the main use cases, but it leaves limit/offset semantics unstated and does not explicitly clarify how to request system announcements (e.g., by omitting course).
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?
With 0% schema description coverage, the description must carry parameter meaning, and it does partially: 'course or system announcements' maps to the course parameter, and 'for detail' clarifies the role of announcement_id. However, limit and offset are never mentioned; their names and schema constraints imply pagination, but the description does not fully compensate for the missing schema descriptions.
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 a specific verb ('Read') and names the resource ('course or system announcements'), which clearly identifies the tool's purpose among the blackboard_* siblings. The second sentence adds a list-versus-detail distinction. It could be more explicit about how this differs from adjacent tools like blackboard_content or blackboard_dashboard, but the resource is unambiguous.
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 gives clear context: this is for reading course-level or system-wide announcements. 'Provide course and announcement ID for detail' is actionable guidance for requesting a specific announcement. It does not explicitly name alternatives or exclusion criteria, but no sibling tool appears to cover announcements, so the context is sufficient.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds helpful scope context ('enrolled courses or organizations') but does not disclose additional behavioral details such as pagination or filtering effects beyond what the schema already exposes.
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 with no filler. The first sentence front-loads the verb and resource, and the second sentence adds high-value workflow guidance about IDs. Every word earns its place.
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?
For a tool with six parameters and 0% schema coverage, the description is too sparse. It correctly identifies the tool's role and mentions organizations, but it omits necessary context about filter semantics, pagination, and the available_only default, leaving an agent to guess or infer parameter behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only hints at 'courses or organizations' and 'list/search.' It does not explain the difference between term and query, the meaning of available_only, or how limit/offset behave, leaving six parameters effectively undocumented.
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 states a specific action ('List/search') on a clear resource ('enrolled courses or organizations') and adds that the returned IDs are preferred for other Blackboard tools. This differentiates it from singular tools like blackboard_course and establishes it as the entry-point listing tool.
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?
'Returned IDs are preferred for all other Blackboard tools' gives an explicit reason to call this tool first before using other Blackboard tools. It does not name specific alternative tools or explicitly say when not to use it, but the workflow guidance is clear enough.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description's non-sending/non-marking-read statement reinforces that profile rather than adding new behavioral context; no contradiction exists.
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 action and resource, with no filler. The second sentence earns its place by stating an important non-behavior.
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?
Despite output schema and annotations covering return shape and safety, the definition omits how the view enum behaves, which filters to use (course, conversation_id), and pagination semantics. For a five-parameter optional tool, the description alone leaves too much for the agent to infer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the five parameters or the meaning of view values beyond vague 'messages/conversations.' The schema provides names/defaults/constraints but no semantic guidance, and the description fails to compensate for the missing parameter context.
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 states a specific verb and resource: 'Read existing messages/conversations.' It also differentiates the tool from any messaging action with 'Never sends messages or marks them read,' and the sibling list shows related blackboard read tools, so the scope is unambiguous.
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 gives clear context for when to use the tool (reading messages/conversations) and an explicit boundary ('Never sends messages or marks them read'), so an agent won't use it for sending. It does not name an alternative tool for sending, which keeps it just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds useful context by clarifying that only *visible* attendees are returned and that sensitive credential-related data is not exported. This goes beyond the annotations and does not contradict them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is only two sentences, with the main purpose front-loaded and the key limitation stated immediately after. There is no filler or repetition of schema or annotation details. It is structurally concise, though it could carry more semantic value.
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?
With readOnly/idempotent annotations and an output schema present, the description adequately covers the tool's scope and exclusions. It does not need to explain return values, and the input schema covers pagination and filter parameters. The main gaps are minor and mostly about parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it does not explain most parameters. The phrase 'details or visible attendee directory' loosely maps to the `view` enum, but event_id, query, limit, and offset semantics are entirely absent. This leaves the agent reliant on the bare schema for 5 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 identifies the resource (a single event) and the two available views: details or visible attendee directory. It also sets boundaries by excluding registration, ticket, and QR credential export, which helps distinguish it from broader event-related tools. It is clear but does not explicitly name a sibling alternative.
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 'Event details or visible attendee directory' gives clear context for when to use this tool. The sentence 'No registration, ticket, or QR credential export' explicitly states what not to use it for. It lacks named sibling alternatives, but the usage context is sufficiently clear.
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?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds value by clarifying the specific capability boundary (no booking/canceling) and the breadth of read modes available, going slightly beyond the generic annotation signals.
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, both informative, with the capability list front-loaded and the key limitation following immediately. No filler, no redundancy, and every word contributes to understanding the tool's scope.
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?
For an 8-parameter multi-view tool with 0% schema description coverage, the definition is too sparse to fully guide construction of specialized queries such as pagination or capacity filters. However, all parameters are optional with defaults, an output schema exists, and annotations cover the safety profile, so the description provides a viable minimum for selecting and initially invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only loosely maps 'filters/details/reservations' to the view modes. It does not explain day, limit, offset, room_id, capacity, duration, or time_of_day, leaving most of the 8 parameters semantically unexplained.
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 identifies the resource (rooms) and the supported read operations (availability, filters, details, reservations), which clearly distinguishes it from sibling tools targeting events, groups, courses, or people. It lacks a single crisp verb like 'get' or 'list,' but the capability list is concrete and the explicit exclusion of booking/canceling sharpens the scope.
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 explicitly states what the tool cannot do ('Cannot book or cancel rooms'), which is an important exclusion that prevents misuse. However, it does not name alternative tools or state exactly when to choose this tool over a sibling, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already communicate read-only, idempotent, non-destructive behavior, so the description does not need to repeat those. It adds helpful context that the call targets a course section and depends on an ID from connects_courses, but it does not disclose pagination behavior or how the section parameter affects the result.
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 delivers the action, resource, and prerequisite with no filler. The key information is front-loaded and every word contributes.
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 presence of an output schema and strong annotations covers safety and return-value concerns, making the minimal description usable for straightforward calls. However, the section enum values and pagination parameters are left unexplained, so the definition is adequate but not fully complete for correct invocation in all cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the provenance of course_id. It does not add meaning for limit, offset, or the section enum, leaving the agent to rely on bare schema types and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Read') and resource ('Connects course section'), and it clarifies that the course ID comes from connects_courses. This makes it easy to distinguish from sibling list tools like connects_courses and from tools for other platforms such as blackboard_course.
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 clearly states the intended use case: read a section of a Connects course using a course ID obtained from connects_courses. It does not explicitly state exclusions or alternative tools, but the prerequisite/source relationship gives enough contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, open-world, and non-destructive behavior, so the description only needs to add context. It does add the resource scope and confirms no transactional side effects, but it does not disclose additional behavioral details such as pagination behavior or result ordering.
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 tight, front-loaded sentence that conveys the tool's purpose and boundaries with no filler. Every word earns its place.
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?
With an output schema and strong annotations, much of the operational context is already provided. However, the relationship between 'fair_id' and the 'fairs' collection, the meaning of 'view', and search/filter behavior are left ambiguous, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for six parameters. It only maps to the 'collection' parameter by listing its enum values; it does not explain 'query', 'limit', 'offset', 'view', or 'fair_id' semantics, leaving the agent reliant on raw schema property names.
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 states a clear verb ('Read') and the exact resources it covers: jobs, mentorships, marketplace, stores, or fairs. It also differentiates itself from transactional operations by explicitly excluding purchases, applications, and payments.
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 gives clear context by saying the tool is for reading a defined set of collections, and it adds an explicit boundary with 'No purchases, applications or payments.' It does not name specific sibling alternatives, but the scope is clear enough to route an agent correctly.
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?
The description adds valuable behavioral details beyond the annotations: date filtering is applied per upstream page, next_offset should be followed even on empty filtered pages, dates must be ISO, and there is a maximum 31-day window. This gives the agent practical knowledge about pagination and constraints that annotations do not provide.
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 compact and well-organized: it leads with the resource, then states the critical pagination behavior and date constraints. Every sentence earns its place, and there is no redundant or filler 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?
The description covers the most important operational details: date format, filter window, and pagination behavior, while the output schema presumably documents return values. The main missing piece is the meaning of the 'calendar' parameter and explicit differentiation from nearby tools, but overall the tool can be invoked correctly with the given information.
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?
With 0% schema description coverage, the description must compensate for the bare input schema. It adds meaning for start/end by specifying ISO format and the 31-day window, and it clarifies how offset should be used with next_offset. However, it does not explain the 'calendar' parameter or provide any semantics for 'limit', leaving gaps for those 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 identifies the resource as the student schedule, and the surrounding details about date filtering and pagination make it evident the tool retrieves schedule data. It does not explicitly state a verb like 'list' or 'get', and it does not differentiate from sibling tools such as connects_events, so it misses the top score.
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 phrase 'Student schedule' implies this tool is for retrieving schedule-related data, and the date-window constraint gives some context for when it applies. However, there is no explicit guidance about when to prefer this over siblings like connects_events or blackboard_calendar, and no exclusions or alternative routing are provided.
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?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, but the description adds value beyond them by specifying that the tool works from recorded data and does not fabricate proof. This clarifies that the output reflects existing records rather than newly created or manipulated attendance evidence. That is a meaningful behavioral disclosure not fully contained in the annotations.
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 no filler, front-loaded with the verb and object. The negative statement is useful and earns its place. It is concise while conveying scope and exclusions.
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?
Given five parameters, an enum, and no schema-level descriptions, this short description is insufficient for confident invocation. It does not explain the view variants, how meeting_id is used, or pagination behavior via limit and offset. The output schema exists, but the parameter ambiguity remains a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate for that gap. It only loosely aligns 'attendance or class meetings' with the view enum, but it gives no guidance on course, limit, offset, meeting_id, or the difference between 'meetings' and 'meeting'. Five parameters are effectively left unexplained, so the description adds minimal semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and resource ('recorded attendance or class meetings'), making the core purpose immediately clear. It also distinguishes itself from any action-oriented tool by stating what it does not do: check in, fabricate proof, or change attendance. This is sufficiently distinct from siblings like blackboard_grades or blackboard_courses, which target different domains.
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 clearly establishes when to use this tool: when you need to read existing attendance records or class meetings. It also gives an explicit when-not by stating that it does not perform check-ins, fabricate proof, or modify attendance. However, it does not name any alternative tool to use for those operations, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive, and open-world behavior, so the safety profile is covered. The description adds useful behavioral constraints beyond that—event queries need ISO dates, a 28-day max range, and a default window when no dates are supplied—but it doesn't describe return format or pagination, so 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences carry three distinct pieces of information: resource types, date constraints, and default behavior. No filler; constraints are placed before the fallback behavior.
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 read-only query tool with an output schema and thorough annotations, the description covers the key operational details: what views return, required date format, maximum range, and default window. Gaps are the missing explicit verb and no guidance on pagination or when to prefer a sibling tool, but these are minor given schema and annotations.
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 has no descriptions (0% coverage), so the description must compensate. It explains the semantic mapping of view values to 'deadlines/events/calendar definitions/activity' and gives crucial formatting and range constraints for since/until (ISO, <=28 days) plus default behavior. It doesn't mention limit/offset, but those are numeric and have clear bounds in the schema.
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 names the resource areas ('Deadlines, events, calendar definitions, or activity') and the tool name indicates a calendar, so the domain is clear. However, it never states an explicit verb like 'get' or 'list', and it does not contrast with sibling calendar-related tools, so it is clear but lacks explicit differentiation.
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?
Provides concrete conditions: events require ISO since/until, the range must be <=28 days, and omitting dates falls back to Blackboard's default to-do window. This is clear context for when certain arguments should be used, though it doesn't name alternative tools or explicitly state when not to use this tool.
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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the tool's safe read-only nature is covered. The description adds scope context (Connects vs Blackboard) but does not disclose pagination, data freshness, authentication requirements, or other behavioral details. This is adequate but not rich beyond the annotations.
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 sentences with no filler. The first sentence front-loads the core action, and the second adds a valuable routing note. Every word earns its place.
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-only paginated list tool with an output schema and detailed annotations, the description covers the main scope and the key alternative context. It does not explain what 'Connects' is or when to use connects_course singular, but the core invocation needs are satisfied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description says nothing about limit or offset. The schema provides defaults and constraints, but the description does not compensate for the lack of parameter documentation. An agent must infer the pagination meaning entirely from the parameter names and schema bounds.
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 action and resource: 'List Connects courses.' The second sentence explicitly separates this tool from Blackboard tools, so an agent can distinguish it from siblings like blackboard_courses. It is concise and unambiguous about what the tool does.
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 gives a clear exclusion: for LMS readings, assessments, and grades, use Blackboard tools. This helps an agent avoid using connects_courses for LMS-related work. It does not explicitly mention the singular connects_course sibling or provide a more detailed when-to-use comparison, but the main routing guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds meaningful nuance by stating 'without changing read state,' which clarifies that even though it reads, it does not mark items as read. It also surfaces 'visible viewer records,' adding visibility-filter context not present in annotations.
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, well-structured sentence with no filler. It front-loads the core read action and immediately clarifies read-only scope and its distinction from posting and read-state changes. Every word earns its place.
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?
Although annotations and output schema cover safety and return details, the description lacks critical invocation context. An agent cannot determine that post_id is likely needed for the 'post' view, when group_id should be used, or how the views map to required parameters. For a tool with five parameters and 0% schema coverage, this is an incomplete description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the five parameters. It only loosely maps to the view enum by listing feed posts/comments/photos/viewer records, but it does not explain how post_id, group_id, limit, and offset interact with each view. This leaves parameter semantics significantly underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description begins with a specific verb ('Read') and names the exact resources: feed posts, comments, photos, and visible viewer records. It also explicitly distinguishes itself from posting or changing read state, making its purpose clear and differentiable from sibling tools.
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: use this tool to read feed-related content and not to post or alter read state. It does not explicitly name alternatives or exclusions beyond 'without posting or changing read state,' but the positioning is strong enough for an agent to select it appropriately.
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?
Annotations provide only generic hints (all false), so the description carries the burden of behavioral disclosure. It reveals side effects: 'Clears only this process's cached session, never logs the browser out,' and explains source-specific behavior. This goes beyond the structured annotations and gives the agent important safety-relevant context.
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 sentences with no filler, each contributing distinct value: purpose, usage timing, side effects, and source edge cases. The most important action is front-loaded. This is appropriately concise for a configuration tool.
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?
With an output schema present, return values are not the description's job. The description covers when to use it, side effects, and source-specific behavior, but omits any explanation of the required `service` parameter, which is critical for correct invocation. It also does not say what 'persist' implies for future sessions beyond clearing cache. The overall picture is functional but incomplete.
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 0%, so the description must compensate. It indirectly covers browser, profile, and source ('browser selection', 'profile/source', 'Isolated'/'managed'), but it never explains the required `service` parameter (connects/blackboard). This is a meaningful gap for the one required field, though the other parameters receive partial context.
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 states a specific action ('Persist non-secret browser selection') and indicates it configures auth after a user chooses a profile/source. This distinguishes it from siblings like ie_login_start or ie_auth_status, though 'non-secret browser selection' is somewhat roundabout. Overall the core purpose is clear.
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 explicitly says 'Use after the user chooses a profile/source,' giving a clear trigger condition. It also differentiates source behavior ('Isolated needs no normal-browser extraction; managed uses OpenClaw port 18800'), which helps route the agent. It does not explicitly name alternatives or exclusions, but the context is sufficient.
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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context with 'bounded output', indicating the result is intentionally limited rather than exhaustive—useful behavioral information beyond the annotation set.
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, tightly-worded sentence covers the tool's scope and a key output constraint. Every phrase earns its place, and the main subject ('Blackboard ... summary') is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, rich annotations covering safety, and an existing output schema, the description is sufficient. It names the data domains included and signals the bounded nature of the output, so an agent can correctly select and invoke the tool without ambiguity.
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 input schema is effectively complete and the description does not need to explain parameter meanings. Baseline for zero-parameter tools applies and the description's category list gives the agent enough context about what the output will cover.
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 as a summary aggregation of Blackboard identity, courses, to-do, activity, and messages, which distinguishes it from granular siblings like blackboard_courses or blackboard_messages. It lacks an explicit verb like 'get' or 'retrieve', but 'summary' implies a read operation.
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 a bounded cross-domain snapshot of Blackboard is needed, this tool fits. It does not explicitly state when to prefer it over connects_dashboard or the granular blackboard_* tools, nor does it mention 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool readOnly, idempotent, and non-destructive; the description adds useful context by emphasizing only visible grades and EXISTING attempts/feedback, and by ruling out test/attempt creation. This aligns with and enriches the annotations.
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-load the resource scope and then state the critical negative behavior. There is no filler, and the emphasis on 'EXISTING' and 'Never' is purposeful.
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 read-only safety context is complete, but the tool exposes six parameters and nine view modes with no guidance on what each returns or how column_id/attempt_id should be used. An agent could invoke it safely but may not select the correct view or filters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain the six parameters, but it does not mention course, view, limit, offset, column_id, or attempt_id. Parameter names and the view enum are self-suggestive, yet the description adds no semantic detail beyond them.
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 identifies a clear read-only purpose: returning visible grades and existing attempts/feedback. The explicit negation 'Never starts a test, creates an attempt or submits answers' differentiates it from assessment-related siblings without needing to open schemas.
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 gives an explicit when-not boundary by stating the tool never starts tests or creates attempts, which prevents misuse for assessment-taking. It does not name the alternative tool, so it stops short of fully routing the agent.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds a domain-specific reassurance ('Never changes connections') that reinforces the read-only behavior, but it does not disclose additional behavioral traits such as authentication needs, rate limits, or open-world search behavior beyond what annotations imply.
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 compact and front-loaded: it immediately states the operation, the identifier requirement, the optional view, and the safety boundary in two short sentences. Every phrase contributes useful information without unnecessary elaboration.
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 read-only tool with rich annotations and an output schema, the description covers the key invocation requirement: identifying a person by returned ID/UID or exact full name. It lacks an explicit pointer to when connects_people would be more appropriate and does not describe all view options, but the schema enum and output schema fill most of the remaining gaps.
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 0%, so the description must compensate. It does clarify the critical `person` parameter by specifying it accepts a returned ID/UID or an exact full name, and 'visible connections' hints at the `view` parameter. However, it does not explain `limit`, `offset`, or the `view` enum variants like `mutual` and `suggestions`, leaving some parameters to rely on their schema titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Read'), resource ('a profile'), and scoping condition ('by returned ID/UID or exact full name'). It also mentions optional connection viewing, which differentiates this from the sibling connects_people by indicating this is for resolving a specific known person rather than listing/searching broadly.
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 explicitly communicates when to use the tool: when you already have a returned ID/UID or an exact full name. It also states a clear boundary ('Never changes connections'), which helps an agent avoid using it for mutation. It does not explicitly name alternatives or exclusions, but the use condition is clear enough.
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?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these: 'no enrollment changes' makes the specific non-mutating promise explicit (reassuring for a groups tool where membership mutation is a common concern), and 'visible membership' discloses that only visible memberships are returned, implying restricted data scope. These go beyond the generic read-only annotation without contradicting it.
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 10-word sentence with zero filler. The verb 'Read' is front-loaded, the resource scope follows immediately, and the behavioral caveat is appended efficiently. Every word earns its place.
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?
An output schema exists, so return values need not be explained, and annotations cover the safety profile. The description adequately covers what is read and the scope, but gaps remain: the relationship between view and group_id is undocumented, pagination semantics (limit/offset) are unaddressed, and the meaning of 'visible' in 'visible membership' is not elaborated. Adequate for a read-only tool, but not complete for a 5-parameter tool with zero schema descriptions.
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 0%, so the description must compensate, and it partially does: 'course groups, group sets and visible membership' map naturally to the view enum values (groups, sets, members). However, it adds no meaning for course, limit, offset, or group_id, and it does not clarify interactions such as whether view=members requires a group_id. The parameter names and schema constraints are self-explanatory enough to keep this at baseline, but the compensation is incomplete.
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?
States a specific verb ('Read') and precise resources ('course groups, group sets and visible membership'), which cleanly distinguishes this from siblings like blackboard_content, blackboard_grades, and connects_groups. The phrase 'with no enrollment changes' further sharpens the scope. An agent can tell exactly which resource domain this tool covers.
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 gives clear context: it is a read-only view of groups/sets/memberships. The clause 'with no enrollment changes' implicitly provides a when-not—do not use this for modifying enrollments—though no alternative tool is named. Among siblings, none obviously handles Blackboard group enrollment mutations, so the missing routing is not a serious gap, but explicit guidance would push this to 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?
Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable behavioral context beyond the annotations: it states the check is live, requires no browser, and provides the important caveat that outages should not be misinterpreted as logged-out states. This is exactly the kind of interpretive guidance an agent needs.
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 concise sentences with the primary action front-loaded. The first sentence states what the tool does; the second provides a necessary interpretive caveat. No filler or redundant information is present.
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-only status tool with one enum parameter, rich annotations, and an output schema, the description covers the essential semantic point and adds the critical outage caveat. However, it omits any mention of the 'service' parameter and does not clarify how it relates to sibling auth tools, leaving a moderate gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining the parameter. It does not mention 'service' at all or explain that it selects the platform (connects or blackboard) to check. While the enum values are self-explanatory, the description fails to close the documentation gap for this required parameter.
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 and resource: 'Check live sign-in without opening a browser.' This clearly communicates the tool's function and distinguishes it from browser-based login flows. The caveat 'Outages are not logged-out states' further clarifies the intended interpretation of the result.
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 phrase 'without opening a browser' implies a contrast with browser-based tools, but no alternatives are named and there is no explicit when-to-use or when-not-to-use guidance. The description does not differentiate this from similar siblings like ie_login_status, leaving the agent to infer the appropriate context.
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?
The description adds 'No network,' a meaningful behavioral trait beyond the annotations' readOnlyHint and idempotentHint, indicating the tool does not perform network calls and can be used offline. It also reveals that the tool returns instructional content (setup, sign-in steps, examples, scope), which clarifies its non-mutating nature.
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 with no filler, front-loading the key directive 'Start here' and then enumerating the tool's contents. Every phrase adds value, and 'No network' is a deliberately compact behavioral note.
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 onboarding tool with rich annotations and an output schema, the description covers the essentials: what the tool provides, its offline nature, and the fact that it is the starting point. It could go slightly further by explicitly stating the return format or that it is a guide, but the current text is sufficient 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?
The input schema has zero parameters and schema coverage is 100% by vacuity, so the description need not explain any parameters. For a no-argument tool, the baseline is 4, and the description appropriately focuses on what the tool returns rather than parameter syntax.
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 opens with 'Start here,' clearly identifying this tool as the onboarding entry point, and lists its contents: setup, browser sign-in steps, usage examples, and scope. It is distinct from the action-oriented siblings like ie_login_start or ie_auth_status, though it does not explicitly name them.
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?
'Start here' explicitly signals that this tool should be invoked before other ie_* tools, providing clear usage sequencing. The intent is implied rather than fully explicit—it does not name alternatives or say 'when not to use'—but it remains the strongest possible guidance for a getting-started tool.
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?
Annotations already cover the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the bar is lower. The description adds value beyond annotations by explicitly stating the tool has no side effects on learning progress or external systems: 'Does not mark content complete or launch LTI/tests.' This is meaningful behavioral context an agent would not otherwise know.
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 short sentences, each earning its place: the first defines the core actions, the second gives a usage tip, the third states exclusions. The most important information is front-loaded, with zero filler or repetition of schema/annotation data.
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 read-only browse tool with rich annotations and an output schema, the description covers the essentials: what it operates on, how to handle large result sets, and the behavior boundary (no completion/LTI side effects). The only minor gap is lack of explicit sibling routing, but the exclusion statement partially compensates.
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 0%, so the description must compensate. It does map the view enum values ('Browse ROOT/folder children' → children, 'search' → search, 'list links/attachments' → links/attachments, 'inspect content' → item) and implies offset/limit usage via 'Traverse children for large courses.' However, it does not explain the semantics of course, content_id, or query directly, leaving those parameters under-documented.
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 specific verbs and resources: 'Browse ROOT/folder children, inspect content, search or list links/attachments.' This clearly differentiates the tool from siblings like blackboard_grades, blackboard_assessments, and blackboard_calendar. The clause 'Does not mark content complete or launch LTI/tests' further disambiguates it from content-launch or assessment tools.
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 gives operational guidance: 'Traverse children for large courses' signals when pagination/iteration is warranted. The exclusion clause 'Does not mark content complete or launch LTI/tests' provides a when-not-to-use boundary. However, it never names explicit sibling alternatives (e.g., 'use blackboard_assessments for grading'), leaving some routing to inference.
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?
The description goes well beyond the annotations by disclosing side effects and safety behavior: it generates a private local file, never overwrites, never executes, rejects arbitrary URLs/paths, and enforces a 100 MiB size limit. This is valuable context that the annotations alone do not provide.
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 tight sentences front-load the core purpose, then add constraints, safety guarantees, and return value summary. Every sentence earns its place with no filler or redundant restatement of the tool name.
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 straightforward download tool with an output schema, the description covers key invocation facts: size limit, local side effect, no overwrite/execution, and return contents. The main gap is not explicitly pointing the agent to sibling tools for retrieving valid course/content/attachment IDs, but this is a minor omission given the clarity of the parameter names.
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 0%, so the description carries the burden, but it only partially compensates. The parameter names are self-explanatory and the phrase 'existing attachment' clarifies attachment_id, yet the description does not explain relationships between course, content_id, and attachment_id or how to discover valid values.
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 and resource: 'Download an existing attachment' with a size constraint and explicit destination. It also clarifies what it does not do ('No arbitrary URL/path, no overwrite or execution'), making it clearly distinguishable from related content-listing siblings like blackboard_content.
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 intended use case is implied: use this when you need to download an existing attachment identified by course, content_id, and attachment_id. However, it does not explicitly state when to prefer this over alternatives, nor does it mention how to obtain the required IDs from sibling tools such as blackboard_content or blackboard_course.
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?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds a meaningful behavioral disclosure: it does not return cookie values, and limits results to 'normal' profiles. These details go beyond the annotation metadata.
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, tightly worded sentence that front-loads the action and includes a relevant exclusion. No filler, repetition, or unnecessary detail.
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 zero-parameter, read-only listing tool with an output schema, the description is sufficient. The 'no cookie values' note addresses the most likely security or scope question an agent might have.
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 accepts zero parameters, so there are no parameter semantics to document. The description aligns with the empty input schema, and zero-parameter tools receive a baseline score of 4.
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?
States a specific verb ('List'), a clear resource ('normal Chrome/Brave/Edge/Chromium profile names and IDs'), and explicitly excludes cookie values, which distinguishes it from tools that might access browser data or cookies.
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 usage context is implied by the description: use it when you need the list of normal browser profile names and IDs. No alternatives or when-not-to-use conditions are stated, so it stops at implied guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey read-only, idempotent, non-destructive behavior. The description adds valuable behavioral context beyond that, namely that no browser is opened and that the tool only reflects the active sign-in job's status. It does not fully explain what 'expiry' means, but enough is disclosed.
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, no filler, with the core action first and the routing guidance second. Every phrase earns its place.
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-only status probe with annotations, an output schema, and a single enum parameter, the description is largely sufficient. It could be slightly more explicit about what 'expiry' refers to and how this relates to starting a login, but the core selection and invocation context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the required 'service' parameter at all. The schema's enum provides valid values (connects/blackboard), but the description adds no guidance about which service to pass or why it matters.
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 action and resource: 'Check the active sign-in job.' It also adds a key distinguishing trait, 'does not open a browser,' and names a sibling tool for the later auth state, making the purpose 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?
It gives explicit routing guidance: after expiry, use ie_auth_status to detect a sign-in completed later. This tells the agent both when this tool is appropriate and when to switch to a specific alternative.
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?
Beyond the annotations, the description discloses important runtime behavior: it returns immediately, the login session depends on human password/MFA entry in the browser, and it rejects credentials and arbitrary URLs. This meaningfully adds context about side effects and limitations that annotations alone do not convey.
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 compact and front-loaded with the core operation, then follows with behaviorally important caveats. Every sentence earns its place and there is no filler.
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 that only starts a human-driven SSO flow, the description covers its trigger, immediate return behavior, human-only authentication, and non-acceptance of credentials/URLs. Combined with the schema enum and output schema, an agent has enough context 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 single service parameter is fully defined by the schema's enum (connects or blackboard), but the description itself adds no explanation of how the parameter influences the login target. With 0% schema description coverage, the description doesn't compensate, though the enum mitigates the gap.
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 states a specific action (open or reuse the selected browser), a target (IE/Microsoft SSO), and a condition (only when the user wants to sign in). It also differentiates itself by explicitly saying it does not accept credentials or arbitrary URLs, which distinguishes it from auth configuration or URL-navigation tools.
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 gives a clear condition: use only when the user wants to sign in, and it warns that passwords/MFA are human-only and credentials cannot be supplied. However, it does not explicitly name alternative sibling tools or say when to prefer them instead.
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

IE Student MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![IE Student MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/victor-gurbani/IEStudentMCP/badges/card.svg)](https://glama.ai/mcp/servers/victor-gurbani/IEStudentMCP)

Score Badge

Copy to your README.md:

[![IE Student MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/victor-gurbani/IEStudentMCP/badges/score.svg)](https://glama.ai/mcp/servers/victor-gurbani/IEStudentMCP)

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/victor-gurbani/IEStudentMCP'

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