uniboh

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Tools are clearly separated by subsystem prefixes (almaesami_, rps_, sol_, unibo_, virtuale_), and within each, purposes are distinct. The deprecated alias virtuale_browser_login is explicitly noted, preventing confusion.
Naming Consistency4/5
Overall pattern is subsystem prefix + verb_noun (e.g., almaesami_get_exam_history). Minor inconsistencies: some use 'list' vs 'get' (e.g., almaesami_list_appelli vs almaesami_get_exam_history), and one alias (virtuale_browser_login) differs.
Tool Count4/5
35 tools is high but justified by integrating multiple university subsystems (AlmaEsami, RPS, SOL, Virtuale, calendar). The count is appropriate for the broad scope, though could be streamlined.
Completeness4/5
Covers a wide range of read-only operations (exams, attendance, career, courses, quizzes, files, calendar). Minor gaps: no exam booking, no write actions beyond session management, and no detailed grades beyond career summary.
Average 3.6/5 across 35 of 35 tools scored. Lowest: 1.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under ISC License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds no additional behavioral context, such as authentication requirements, rate limits, or what happens if the session is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single vague sentence that provides no valuable information beyond the tool name. It is under-specified rather than concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high parameter count (7, all optional with defaults) and no output schema, the description is completely inadequate. An agent cannot determine what the tool returns, how to filter or paginate, or how it relates to other tools.
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?
With 0% schema description coverage, the description must explain the parameters' meaning. It does not mention any of the 7 parameters (sort, limit, offset, session_id, classification, customfieldname, customfieldvalue), leaving the agent to infer their semantics from names and enums only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only states that it calls a local API for the authenticated user, but does not clarify what data is retrieved. The name 'get enrolled courses' suggests the purpose, but the description fails to confirm this or state the resource returned.
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 provided on when to use this tool versus its many siblings (e.g., virtuale_get_course_state, virtuale_get_resource). There is no mention of prerequisites, context, or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral context beyond the annotations (readOnlyHint, openWorldHint). It does not describe side effects, authentication needs, or what happens when the course has no Panopto content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence) but at the cost of informativeness. Every word is used, but the lack of detail outweighs the conciseness benefit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, so the description should explain the return value. It does not. With 0% schema coverage and no parameter guidance, the tool description is far from complete.
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 coverage is 0%, and the description does not explain the courseid or session_id parameters. Without any parameter descriptions, the agent receives no assistance in understanding what values to provide.
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 states the tool calls block_panopto_get_content for a course, providing a specific verb and resource. However, 'Panopto block content' is not clearly defined, and it lacks differentiation from sibling tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool vs alternatives. The description simply says it calls a function, with no context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies mutation ('creates') but does not disclose side effects, permissions, idempotency, or what 'server-side session' entails. Agent is left guessing about safety and state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. But it is too brief and lacks structure for a 4-param tool. Conciseness is okay, but at the expense of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters, no output schema, and no annotations, the description is severely lacking. It does not explain return value, error behavior, or how the session is used afterwards. Completely insufficient for an agent to use correctly.
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%. Description only mentions the two required params (sesskey, cookies) in purpose but does not explain email_label or include_cookie_header. No additional meaning beyond property names.
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?
Description clearly states verb 'creates' and resource 'server-side session' with inputs 'sesskey and cookie header'. However, among siblings like almaesami_bootstrap_session, rps_bootstrap_session, and sol_bootstrap_session, it does not differentiate what makes this one specific to virtuale.
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 on when to use this vs alternatives. There are many sibling bootstrap_session tools but no context about prerequisites or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds minimal behavioral context beyond the annotations. It mentions parsing a JSON string, but no details on side effects, permissions, or return format. Annotations already indicate readOnly and openWorld, so the description does little to enhance transparency.
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 with no wasted words. It efficiently conveys the core action, but the structure could be improved by integrating parameter explanations.
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 no output schema and zero parameter descriptions, the description is far from complete. It fails to inform the agent about the state model contents, any usage constraints, or how to interpret the result.
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?
With 0% schema description coverage, the description should compensate by explaining parameter meanings. It does not mention courseid or session_id at all, leaving the agent with no additional insight beyond the schema's type constraints.
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 that the tool calls a specific core function and parses the returned JSON, indicating the verb and resource. However, it does not explicitly differentiate from sibling tools like virtuale_get_enrolled_courses which also operate on courses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no context about prerequisites or exclusions, and no mention of how it relates to other virtuale tools.
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 readOnlyHint=true and openWorldHint=true, so the description adds minimal behavioral context beyond stating it returns an ICS string. No details on error behavior, rate limits, or handling of large calendars are provided.
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, efficient sentence that conveys the core functionality. However, it sacrifices necessary detail for brevity, making it less useful despite its conciseness.
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 5 parameters, no output schema, and only basic annotations, the description is insufficient. It fails to explain parameter roles, output format details, or dependencies (e.g., needing to use unibo_calendar_resolve_timetable_url first).
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 offers no explanation of parameters. While parameter names are somewhat self-explanatory, terms like 'curriculum' and 'selected_teaching_codes' remain ambiguous, leaving the agent without guidance on valid values or required format.
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 ('Fetches'), the resource ('timetable events'), and the output ('returns an ICS calendar string'). It distinguishes the tool from siblings like unibo_calendar_get_events which likely returns events in a different format.
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 on when to use this tool versus alternatives. The description does not mention prerequisites (e.g., resolve timetable URL first) or provide context for selection among related calendar 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 indicate read-only and open-world behavior. The description adds that it parses HTML, which is a key behavioral trait beyond annotations. 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it omits critical information about parameters and usage context. Not all sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 3 undocumented parameters, no output schema, and no explanation of the parsing process or required session context, the description is severely incomplete for the tool's complexity.
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 coverage is 0% and the description does not explain any of the three parameters (timetable_url, year, curriculum). The description fails to add meaning to the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool parses timetable page HTML and returns lecture/teaching IDs for filtering. It uses specific verbs and distinguishes from sibling tools like list_curricula and get_events.
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 only implies usage for filtering but provides no explicit guidance on when to use, when not to, or alternatives. It lacks prerequisites like requiring a browser login session.
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 readOnlyHint=true, and the description's 'shows' is consistent. The optional cookie header return is a behavioral addition, but no further details on side effects or authentication needs are given. With annotations covering safety, the description adds moderate value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the core function and the optional parameter effect. No redundancy or wasted words.
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?
The description omits critical details: return format (e.g., JSON structure), error cases (e.g., invalid session_id), and any further context about the metadata. Given the lack of output schema, agents are left guessing.
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?
With 0% schema description coverage, the description must compensate but only restates property names: session_id (implied) and include_cookie_header (explicitly 'optionally returns cookie header'). No additional semantics like format or validation constraints are provided.
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 it shows stored login metadata and optionally returns a cookie header, which matches the tool name and purpose. However, it does not explicitly differentiate from sibling tools like virtuale_get_env_session, though the metadata focus provides some distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool vs alternatives, such as bootstrap or env session tools. It lacks prerequisites (e.g., session must exist) and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions login attempt, server-side storage, and session ID return, but does not disclose failure behavior, side effects, or prerequisites. Lacks details on persistence or security implications.
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?
Single, front-loaded sentence with no wasted words. Could be slightly expanded but remains efficient.
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?
Tool has 4 parameters and no output schema. Description lacks details on error handling, session management, password safety, or how the returned session_id should be used. Incomplete for a login 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 coverage is 0%, meaning no parameter descriptions in schema. Description does not explain any parameter beyond types. Critical parameters like 'login_path' and 'include_cookie_header' are left undefined, leaving the agent guessing.
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 clearly states the action (login), the resource (Moodle form), and the outcome (stores cookies/sesskey, returns session_id). It distinguishes from sibling login tools by specifying Moodle form login.
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?
Description implies usage for password-based login but lacks explicit when-not-to-use guidance or alternative tools. Among siblings, there are other login methods (e.g., browser_login, bootstrap_session) that could be mentioned.
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 declare readOnlyHint=true and openWorldHint=true, indicating safe read behavior. Description adds no further behavioral traits beyond the implied read-only nature of 'lists'. Not contradictory, but no value added.
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?
Very concise: one sentence, front-loaded with action verb 'lists', no unnecessary words. Efficient for an agent to parse.
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?
Adequate for a simple list tool with clear annotations. Lacks context on what 'curricula' are, any prerequisites (e.g., login?), or connection to other tools. Moderately 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 coverage is 0%, so description must compensate. Merely states 'for a timetable URL' without explaining the parameter's role, format, or how to obtain it. Inadequate for a single 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?
Description clearly states the action ('lists') and resource ('available curricula') with context ('for a timetable URL'). However, it does not differentiate from sibling tools like 'unibo_calendar_list_teachings', missing a chance to distinguish purpose.
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 on when to use this tool versus alternatives like 'unibo_calendar_list_teachings' or 'unibo_calendar_resolve_timetable_url'. Missing exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and openWorldHint. The description adds minimal behavioral context beyond stating 'Read-only' and listing output fields, failing to disclose auth requirements, error handling, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the purpose and contains no fluff. Every word contributes to understanding.
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 no output schema, the description lists output fields but lacks detail on structure, ordering, or edge cases. Input parameters are not fully explained in context, but the tool is simple enough that the description is minimally adequate.
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 67% (cookies and session_id described, base_url missing). The description adds no additional meaning to parameters beyond what is in the schema, missing an opportunity to explain base_url or relationship to session parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the authenticated student's RPS attendance records, listing specific fields (date, subject, lecturer, lesson duration). It uses the verb 'reads' and specifies the resource, distinguishing it from siblings like rps_get_register.
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 on when to use this tool versus siblings or prerequisites. The description implies an authenticated session but does not provide context on obtaining credentials or comparing to other RPS tools.
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?
Discloses that the cookie is not echoed back and returns an opaque session_id, but lacks details on error conditions, session lifetime, or idempotency. With no annotations, this is a moderate effort.
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, no fluff. Every word adds value.
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?
Adequate for a simple bootstrap tool, but missing workflow context (e.g., that this precedes other almaesami tools) and error behavior. No output schema shifts burden to description, which is only partially met.
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 coverage is 50%; description only repeats the cookie schema description and does not explain the 'label' parameter. Fails to compensate for undocumented parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (creates) and resource (server-side session from existing cookie), and distinguishes from siblings like rps_bootstrap_session by specifying the almaesami domain.
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 on when to use this tool versus alternatives (e.g., almaesami_get_env_session) or when not to use it. The context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds 'Read-only' (redundant) and specifies the return content (hours and percentage), providing some value beyond annotations. However, it does not disclose any behavioral traits like authentication failure handling or data freshness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and output. Every word adds value, with no redundancy or 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?
Given the tool has 3 parameters and no output schema, the description provides essential return content. However, it omits prerequisites (e.g., need for a valid session), authentication steps, and does not clarify how the tool relates to sibling tools, leaving gaps for a complete understanding.
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?
With schema description coverage at 67%, the description adds no information about parameters beyond what the schema already provides. Parameters like 'cookies' and 'session_id' are not mentioned, missing an opportunity to explain authentication flow or fallback logic.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the authenticated student's RPS attendance register, specifying the exact data returned (per-subject hours and percentage). It effectively distinguishes from sibling tools like 'rps_get_attendance_records' by focusing on aggregated register data.
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 lacks any guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use, or explicitly compare with the sibling 'rps_get_attendance_records' tool, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds no behavioral details beyond the annotations (readOnlyHint, openWorldHint). It does not disclose error handling, output format, or side effects, but the annotations already set expectations for readonly and open-world behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, focused sentence that efficiently conveys the tool's purpose without unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a one-parameter, no-output-schema tool, the description covers the essential input-output relationship. It lacks details on edge cases but is sufficient for basic use.
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 coverage, the description partially compensates by indicating the parameter type (course page URL) and expected output (timetable URL). However, it does not describe the exact URL format or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('resolves') and the specific resource (timetable URL from a course page URL). While it distinguishes the tool from siblings by its unique purpose, it could be more explicit about what 'resolve' entails.
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 provided on when to use this tool vs alternatives, nor are there any preconditions or contexts mentioned. The description lacks any usage recommendations.
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=true, so description's 'Read-only' reinforces that. It adds behavioral detail by specifying return content (status, dates, marks, grade, review URL/attempt id). This goes beyond annotations, though it could mention side effects (none) or what happens with no attempts.
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, front-loaded with the main action and output. No extraneous information. Efficient for an API tool description.
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 4 parameters, no output schema, and no parameter descriptions, the description is incomplete. It lacks parameter usage, return format, and edge case handling. Adequate only for very minimal tool understanding.
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 description does not explain any parameter. Required 'cmid' is not described; optional parameters (cookies, base_url, session_id) are omitted. Description adds no semantic value beyond parameter 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 clearly states the tool reads a quiz activity page and returns student attempt summaries with status, dates, marks, grade, and review URL/attempt id. The verb 'reads' and resource 'quiz activity page' are specific, and it distinguishes from sibling tools like 'virtuale_quiz_get_attempt_review' and 'virtuale_quiz_list_course_quizzes' by focusing on listing attempts.
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?
No explicit guidance on when to use this tool versus alternatives. The description implies usage for listing attempts for a specific quiz, but it does not mention exclusions or direct comparisons to siblings like 'virtuale_quiz_get_attempt_review' for individual review details.
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 and openWorldHint. Description adds the data source (@@orario_reale_json) but little beyond that, so marginal value.
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?
Single sentence, no wasted words, effectively conveys core functionality.
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?
Lacks information about return format, pagination, or data structure. Adequate for a simple tool but incomplete given 4 parameters and no output schema.
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 coverage is 0%, so description must compensate. It only explains 'selected_teaching_codes' (optional filter) but omits meaning of year, curriculum, timetable_url.
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 clearly states verb 'Fetches' and specific resource 'raw timetable events from @@orario_reale_json' with optional filtering. Distinguishes from sibling tools like unibo_calendar_get_ics.
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?
No explicit guidance on when to use or not use this tool versus alternatives. Usage is implied but not directly stated.
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 indicate readOnlyHint and openWorldHint; the description confirms read-only and adds details: redirect handling, cookie authentication, return metadata, inline text for text/PDF with truncation, and file saving behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph with front-loaded purpose and key details. It is concise with no redundancy, though could be slightly more structured with bullets for clarity.
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?
Return values are described (metadata, file path/size, text extraction) but unclear for binary non-text files without save_to. No mention of error handling or authentication requirements beyond cookies. Adequate but with gaps given complexity.
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 partially compensates by explaining cmid/url identification and save_to disk saving, but fails to detail parameters like base_url, session_id, and cookies beyond a mention. Some parameters remain 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 clearly states the tool fetches a Virtuale file/resource by cmid or URL, with specific behavior like following redirects. While it doesn't explicitly distinguish from sibling 'virtuale_list_course_files', the action of fetching a single resource vs listing is evident from context.
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 provides guidance on when to use save_to (for full file) vs inline text, but does not explicitly compare with alternative tools or state when not to use this tool. No exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states that the tool removes a session from server memory, indicating a destructive action. However, it does not explain error handling (e.g., if session doesn't exist), side effects (e.g., invalidating tokens), or authentication requirements for using this tool. Basic transparency but insufficient depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is both concise and front-loaded with the core action. Every word earns its place; there is no extraneous information. This is exemplary conciseness for a simple 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?
For a simple tool with one required parameter and no output schema, the description provides the essential action but omits critical context: success/error behavior, prerequisites (e.g., session must be active), and post-conditions. The gaps lower its completeness to an adequate but not thorough level.
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 parameter meaning. It does not mention the 'session_id' parameter at all. While the parameter name is somewhat self-explanatory, the description adds no value beyond the schema definition, leaving agents without context on what value to provide.
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 ('removes'), the resource ('one stored authenticated session'), and the scope ('from server memory'). It distinguishes from sibling tools like bootstrap_session or login tools, which create or manage sessions, not destroy them.
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 (to end/remove a session), but provides no explicit guidance on when to use this tool versus alternatives, prerequisites (e.g., must have an active session), or contraindications. The context makes it moderately clear, but lacks direct instruction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It states the cookie is never echoed back, which is good, but lacks details on side effects, authorization, or error handling. The agent is left to infer that this is a non-destructive read operation, but the description does not confirm or deny.
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, using two sentences to convey purpose, input, and output. Information is front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description covers the essential aspects: input (cookie), action (create session), output (opaque ID), and a notable behavior (cookie not echoed). It lacks error conditions or usage context, but for a simple bootstrapping tool, it is reasonably 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 coverage is 50%. The description adds minimal value beyond the schema: it repeats the cookie description. The 'label' parameter is given a default but no context, and the description does not explain its purpose or how to use it appropriately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: creating a server-side session from a SOL cookie header. It specifies the source (studenti.unibo.it) and the output (opaque session_id). This distinguishes it from sibling session tools for other domains.
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 (when having a JSESSIONID cookie from studenti.unibo.it) but does not provide explicit guidance on when to avoid or alternative tools. There is no mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. Reveals that the cookie is never returned and that it may reuse sessions (mint or reuse). However, lacks details on cache duration, error conditions, or auth requirements beyond the env var.
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, no wasted words. Front-loaded with the key verb and resource, then adds critical behavioral detail. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, no-output-schema tool, the description is largely complete: explains what it does, the env var backing, and what it returns. Could specify conditions for mint vs reuse, but overall sufficient.
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?
No parameters exist, and schema coverage is 100%. The description adds value by explaining the behavior (env-backed, opaque session_id) beyond the empty schema. Baseline for 0 params is 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?
Clearly describes the action ('mints or reuses a session_id') and the resource (env-backed session). Distinguishes from siblings by specifying the backing env var and that the cookie is never returned, only an opaque session_id.
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 on when to use this tool over siblings like almaesami_bootstrap_session, rps_get_env_session, etc. Only implied from the description, but lacks direct comparisons or conditions.
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 (safe read) and openWorldHint=true (external changes possible). The description confirms read-only behavior and adds that it does not book exams, which is consistent. No additional behavioral details like error handling or rate limits are provided, but the annotations cover the core safety profile.
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 long with no repetition or filler. Every sentence adds value: the first states purpose and content, the second clarifies read-only nature. It is front-loaded and efficient.
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?
No output schema is provided, but the description lists the return fields (activities, CFU, status, bookable). The tool is straightforward (no nested objects, no enums, 0 required params). However, the missing base_url parameter description and lack of mention of pagination or limits prevent a perfect score.
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 67% (cookies and session_id have descriptions, base_url does not). The description does not mention any parameters, so it adds no meaning beyond the schema. For the uncovered parameter (base_url), there is no compensation. Baseline for this coverage level is around 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'reads' and specifies the resource 'AlmaEsami exam plan (Riepilogo Esami)', listing what it contains (activities, CFU, status, bookable). This clearly distinguishes it from sibling tools like almaesami_get_exam_history (history) and almaesami_list_appelli (list sessions).
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 only states 'Read-only; does not book exams,' which implicitly indicates not to use for booking. However, it does not provide explicit comparisons to sibling tools or conditions for use. There is no guidance on when to use this tool versus almaesami_get_exam_history or almaesami_list_appelli.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that it uses headless Chromium, ADFS SSO, email/password, and returns session_id. However, it lacks details on error handling, security implications, and side effects of force_relogin.
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, front-loaded with the deprecation warning, no wasted words. Efficiently communicates the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its deprecated status and explicit redirection to unibo_browser_login, the description is sufficiently complete for an AI agent to decide not to use it. However, it lacks explanation of the parameter and output details.
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 only parameter 'force_relogin' at all, failing to add meaning beyond 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 clearly states it is a deprecated login tool that uses headless browser and returns session_id. It distinguishes itself from the preferred unibo_browser_login but does not contrast with other login tools like virtuale_login_with_password.
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?
The description explicitly says 'Deprecated alias for unibo_browser_login' and 'Prefer unibo_browser_login', providing clear guidance on when not to use this tool and what alternative to use instead.
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?
Discloses that credentials are never returned and session_id is opaque, which is helpful for security awareness. However, it does not mention failure modes (e.g., missing env vars) or idempotency details beyond 'reuses'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the core action and add a critical security note. No extraneous information.
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?
Covers key aspects: creation/reuse, opaque session_id, and credential protection. Missing prerequisites (env vars must be set) and error handling, but given zero parameters and no output schema, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description correctly provides no parameter-level details. With 100% schema coverage (void), the baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Mints (or reuses) a session_id' using specific environment variables, distinguishing it from sibling bootstrap sessions by emphasizing the env-backed approach.
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 on when to use this tool versus alternatives like virtuale_bootstrap_session or other get_env_session tools. The description lacks comparative context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions that the cookie is never echoed back and returns an opaque session_id, but doesn't cover error handling, idempotency, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences that front-load the purpose and cover key behavioral details. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but the description mentions the return value (opaque session_id). For a simple session bootstrap tool, this is sufficient. However, it could note error conditions or prerequisites.
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 50% (only 'cookies' has a description). The description adds minimal value: it mentions the cookie header but doesn't clarify the 'label' parameter's purpose. The parameter semantics rely heavily on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Creates a server-side session from an existing rps cookie header' and specifies the cookie domain 'rps.unibo.it'. This distinguishes it from sibling tools targeting other systems (e.g., Almaesami, SOL, Virtuale).
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 usage when you have an RPS cookie header. It doesn't explicitly state when not to use it or name alternatives, but the context of sibling tools (e.g., almaesami_bootstrap_session) provides differentiation.
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 and openWorldHint=true, so the agent knows it is read-only and results may vary. The description adds that it returns the cmid, but does not elaborate on other behavioral traits like pagination or authentication details. With annotations covering safety, the description provides adequate but not exceptional transparency.
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 that front-loads the core function ('Lists quiz activities') and immediately states the key output detail (cmid). No extraneous information, earning high marks for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description clarifies that the output includes quiz activities with cmid, which is essential for subsequent tool usage. However, it does not mention any limitations (e.g., pagination) or the structure of the returned data. Overall, it is mostly complete for a list tool but leaves minor gaps.
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?
The schema has 4 parameters (cookies, base_url, course_id, session_id) with 0% schema description coverage. The description only implicitly references course_id via 'course page'. It fails to explain the roles of cookies, base_url, and session_id, or provide any additional meaning beyond the schema. This is a significant gap for a tool requiring authentication 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 clearly states the tool lists quiz activities on a course page and specifies that it returns the course-module id (cmid) needed by other quiz tools. This differentiates it from siblings like virtuale_quiz_list_attempts or virtuale_quiz_get_attempt_review, which focus on attempts and reviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the primary use case: to obtain the cmid for subsequent quiz-related tool calls. While it does not explicitly state when not to use it or list alternatives, the context of sibling tools and the mention of 'needed by the other quiz tools' provides clear guidance on when to invoke this 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 declare readOnlyHint=true and openWorldHint=true. The description reinforces 'Read-only' and adds that the data is for the 'authenticated student', which is a useful behavioral detail beyond the annotations. No contradictions are present.
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 that immediately states the purpose and lists the key data fields. Every part adds value without redundancy or 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 no output schema, the description adequately names the fields returned. However, it could be more complete by indicating whether the result is an array or single object, or if pagination applies. Given the simple nature and presence of annotations, the description is mostly sufficient.
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 input schema describes 3 parameters with 67% coverage (cookies and session_id have descriptions). The description does not add any extra meaning about the parameters beyond what the schema already provides. Given the coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'reads' and names the resource 'AlmaEsami exam history' with a parenthetical Italian term and a list of fields ('appello date, activity, examiner, type/mode, and status'). This clearly distinguishes it from sibling tools like almaesami_list_appelli or almaesami_get_exam_plan, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating 'authenticated student', but does not explicitly tell the agent when to use this tool versus alternatives. It lacks guidance on prerequisites (e.g., need for a valid session) or scenarios where other exam tools would be more appropriate. A clearer indication of when to choose this over almaesami_get_exam_plan or almaesami_list_appelli would raise the score.
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 and openWorldHint. The description adds that the tool reads review data without modifying state, and details what data is returned, enhancing transparency 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?
Two concise sentences: first states purpose and contents, second states limitations. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description sufficiently explains what is returned (each question's text, answer options, selection, correctness, feedback). Constraints are clear. Could be improved by briefly explaining the required parameters.
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 has 5 parameters with 0% description coverage. The description only implicitly references attempt_id and does not explain cmid, cookies, base_url, or session_id. It provides no added meaning for individual parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it 'Reads the review page of one of the student's own finished quiz attempts' and lists exact contents (questions, answers, correctness, feedback). It distinguishes from siblings by specifying it does not start, resume, or answer a live attempt.
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 explicitly states when it works: 'Only works for attempts Moodle already allows the student to review (finished, review permitted by the quiz settings)'. It also clarifies it does not handle live attempts, but does not explicitly name alternative tools for live attempts.
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, and the description confirms read-only behavior, adding that it does not delete messages. It also lists the specific fields returned (subject, sender, etc.), which adds value beyond the annotations. However, it does not elaborate on openWorldHint or other behavioral traits.
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, clear sentence with no unnecessary words. It efficiently conveys the tool's purpose and constraints.
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 tool with no output schema, the description provides a good summary of returned data. However, it does not mention potential limitations like pagination or prerequisites beyond the parameters, which could be helpful. Overall adequate but not exhaustive.
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 description does not add any parameter-specific details beyond what the schema provides. Schema coverage is 67% (two of three parameters have descriptions), but the description does not explain the missing base_url parameter or any parameter behavior, leaving it at baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('reads'), the resource ('AlmaEsami messages'), and the scope ('authenticated student's'). It also explicitly mentions that it is read-only and does not delete messages, distinguishing it from potential mutation 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 indicates the tool is for reading messages and is read-only, implying its use case. However, it does not explicitly mention when to use this tool over alternatives or provide when-not-to-use guidance, though it is clear enough for a simple retrieval 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?
Discloses that the cookie is never returned and that it returns an opaque session_id. With no annotations, this provides good behavioral context, though it could add details on prerequisites or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action, no redundant information. Every phrase contributes meaning.
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 zero-parameter tool with no annotations or output schema, the description covers the essential: what it does, how it works, and what it returns. Could mention that it establishes a session for subsequent RPS calls.
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?
Zero parameters, so baseline is 4. Description adds value by explaining the purpose and what it returns, clarifying the opaque nature of the session_id.
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 clearly specifies the action ('mints or reuses'), resource ('session_id'), and backing ('RPS_COOKIES env var'). It distinguishes from sibling tools like almaesami_get_env_session by specifying the RPS context.
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?
Implies usage through mention of 'RPS_COOKIES env var', but lacks explicit guidance on when to use this over other get_env_session siblings or when not to use it. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fairly discloses that the cookie is never returned and only an opaque session_id is provided. However, it does not mention error handling if the env var is missing or session reuse timeout, which would be beneficial for full transparency.
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 sentences, no unnecessary words, front-loaded with the action verb 'Mints'. Every sentence adds 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?
For a zero-parameter tool with no output schema and no annotations, the description covers the core purpose and key behavioral constraint (cookie not returned). It lacks error case specification but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds value by explaining the env var backing and the opaque session_id behavior. Since schema coverage is 100% (none), the baseline is 4, and the description meets this expectation.
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 verb 'Mints (or reuses)' and the resource 'session_id', distinguishing it from sibling session tools that likely require user credentials or different backing. It specifies the env var source and the opaque nature of the return value.
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 the SOL_COOKIES env var is set but does not provide explicit guidance on when to use this vs. alternative session tools (e.g., sol_bootstrap_session). No when-not-to-use or prerequisite information is given.
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 declare readOnlyHint=true and openWorldHint=true. The description reinforces read-only behavior and adds detail that it lists links without acting on them. It goes beyond annotations by specifying the output fields (name, link, description).
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. Front-loaded with purpose and payload, followed by a clarifying statement on read-only nature. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, the description covers core intent and safety traits. It omits error conditions, pagination, and explicit authentication requirements, but the annotations (openWorldHint) reduce the completeness burden. Adequate for its complexity.
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 tool description does not reference any parameters. Schema coverage is 67% (cookies and session_id have descriptions; base_url lacks). The description adds no additional parameter meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Lists', the resource 'Studenti Online service tiles', and specifies the included fields (name, link, description). Examples distinguish it from sibling tools like sol_get_career.
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 usage for discovering portal services and explicitly states it's read-only. However, it does not compare to alternative tools or provide explicit when-not-to-use 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?
The description adds context beyond annotations by specifying 'safe no-login Moodle AJAX call', confirming the read-only and open-world behavior indicated by annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that conveys all necessary information without waste. Perfectly concise and 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?
For a zero-parameter, no-output-schema health check tool with adequate annotations, the description is fully sufficient and leaves no gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and 100% schema description coverage, the description has no need to add parameter details. Baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'runs' and identifies the resource as a 'Moodle AJAX call' with a clear goal: 'validate base connectivity'. It effectively distinguishes from sibling tools like login or session tools by emphasizing 'no-login'.
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 checking connectivity before other operations via 'safe no-login' and 'validate base connectivity', but does not provide explicit when-not scenarios or alternative tools for similar purposes.
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 and openWorldHint=true, and the description confirms it is read-only. The description adds value by stating the derivation source ('derived from core_courseformat_get_state') and characterizing the output as a 'slim, token-friendly view', which provides performance 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 three sentences, concise, and front-loaded with the core functionality. Every sentence adds distinct value: listing groups, derivation, and usage guidance. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no output schema), the description adequately covers what the tool returns (grouped by section, fields) and its read-only nature. It could be slightly more complete by describing the fields, but the context is sufficient for an agent to use the tool 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% and there are 2 parameters (courseid, session_id). The description does not explain what these parameters mean or how they affect the output. It mentions 'cmid' in the context of the sibling tool but not the parameters of this tool. The description must compensate for low coverage but fails to do so.
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 it lists downloadable files/resources of a Virtuale course, grouped by section with specific fields (cmid, name, modname, url). It explicitly distinguishes itself from sibling tools like virtuale_get_resource (which fetches file content) and virtuale_get_course_state (full state blob).
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?
The description provides explicit guidance: use this tool to get a list of files and then pass a cmid to virtuale_get_resource to fetch content. It also contrasts with virtuale_get_course_state by calling this a 'slim, token-friendly view', indicating when to prefer this tool.
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 (readOnlyHint, openWorldHint), the description adds critical behavioral context: it parses from a single logged-in capture, uses best-effort selectors, and degrades fields to empty rather than failing. This disclosure is essential for the agent to understand reliability and potential edge cases.
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 consists of two concise sentences plus a note, all front-loaded with key information. Every sentence serves a purpose: stating the action, specifying the output, and warning about reliability. There is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (3 parameters, no required, no output schema), the description adequately covers what the tool does and its limitations. It explains the return content and the best-effort nature. Missing details like how to obtain the cookies/session_id are inferable from sibling 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?
Schema coverage is 67% (2 of 3 parameters have descriptions). The tool description does not add any parameter-level information beyond what the schema already provides. Since coverage is high, a baseline of 3 is appropriate; no additional value is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('reads') and clearly identifies the resource (the student's Studenti Online home page into a career summary). It lists the components of the summary (greeting/identity, enrolled course of study, in-progress requests), which effectively distinguishes it from sibling tools like sol_get_services or sol_get_env_session.
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 explicitly states 'Read-only; never submits requests or payments,' clarifying the non-destructive nature. It implies usage when a student's career summary is needed. However, it does not explicitly contrast with alternatives or specify when not to use, which would elevate it 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 readOnlyHint=true and openWorldHint=true. The description adds valuable transparency: it states the endpoint is UNVERIFIED, the result carries unverified:true, and the parser tolerates layout changes. It also clarifies 'Read-only: it never books.' 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with purpose, and every sentence adds unique value: purpose, limitations, and fallback guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description adequately lists what the tool returns (date/time, activity, examiner, type/mode, enrollment window, unverified flag). It also warns about the unverified status. Could mention pagination or error handling, but overall sufficient for a read-only listing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 parameters described in schema). The description adds context for 'path' (default is UNVERIFIED, provide real route), 'cookies' (authenticated JSESSIONID, fallback chain), and 'session_id' (source from other tools). This enhances understanding 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 specifies it lists upcoming AlmaEsami appelli (bookable exam sessions) with details like date/time, activity, examiner, type/mode, and enrollment window, and explicitly states it answers 'when can I sit exam X'. It distinguishes from siblings by noting it's read-only and about bookable sessions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use: to answer when an exam can be taken. It also offers fallback guidance: if it returns nothing, use the exam-plan tool's bookable flags or pass an explicit path. It does not explicitly state when not to use, but the read-only nature is 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?
With no annotations, the description carries full burden. It discloses browser use, password security, best-effort per-service behavior, and session reuse. It does not mention rate limits, but overall provides substantial behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action and each sentence adds value. It covers purpose, usage, behavior, and limitations without redundancy.
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 the simple input schema (one optional boolean), no output schema, and complex task, the description thoroughly explains the tool's role, how it works, and its relationship to sibling tools, leaving no major gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'force_relogin' is explained in the description: 'Mints once and reuses the session on later calls unless force_relogin is set.' This adds critical meaning beyond the schema, compensating for 0% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool drives a headless browser for ADFS SSO login using email+password, completes multiple SAML handshakes, and returns an opaque session_id for use with other tools. It distinguishes from sibling tools like *_bootstrap_session for MFA accounts.
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?
The description explicitly says 'Only works for accounts without interactive MFA (use the *_bootstrap_session tools for MFA accounts)' and notes the session is reused unless force_relogin is set, providing clear guidance on when and 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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![uniboh MCP server](https://glama.ai/mcp/servers/gattaa/uniboh/badges/card.svg)](https://glama.ai/mcp/servers/gattaa/uniboh)

Score Badge

Copy to your README.md:

[![uniboh MCP server](https://glama.ai/mcp/servers/gattaa/uniboh/badges/score.svg)](https://glama.ai/mcp/servers/gattaa/uniboh)

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/gattaa/uniboh'

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