STIL Lab Assistant
Server Details
STIL lab at ETS Montreal — knowledge base and paper search via ArXiv and Semantic Scholar.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.7/5 across 8 of 8 tools scored. Lowest: 2.9/5.
Most tools have distinct purposes, but find_related_work overlaps with search_arxiv and search_semantic_scholar as it combines both sources. Agents might be uncertain which to use for a general literature search.
All tools follow a consistent verb_noun pattern in snake_case (e.g., find_related_work, get_lab_overview, search_arxiv). No mixing of naming conventions.
8 tools is well-scoped for a lab assistant. Each tool serves a clear purpose without unnecessary duplication or bloat.
The tool surface covers key lab information (overview, topics, students, publications) and external searches. Minor gaps like the absence of a tool for getting a specific publication by ID are not critical for the assistant role.
Available Tools
8 toolsget_lab_overviewAInspect
Get an overview of the STIL lab: description, research areas, director, and contact info.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly indicates a read operation ('Get an overview') with no mention of destructive or unexpected behaviors. The listed content items are appropriate for the tool's purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, 12 words, front-loaded with the essential information. No extraneous text; every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema presumed sufficient, the description provides a compact but complete summary of what the tool returns. It covers all relevant aspects for a simple overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so the description adds all necessary meaning. It explains what the overview includes, which is sufficient since no parameters are needed. Baseline of 4 is appropriate here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets an overview of the STIL lab, listing specific components (description, research areas, director, contact info). It effectively distinguishes itself from sibling tools like list_publications or get_student_info by focusing on the lab's general overview.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for obtaining a high-level lab summary, but it does not explicitly state when or when not to use it relative to siblings. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_research_topicsAInspect
Get the main research topics and active projects of the STIL lab.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits. It only states 'Get', implying a read operation, but omits details like whether results are cached, require authentication, or have any side effects. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately conveys the tool's purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and an output schema, the description is largely adequate. It defines the scope of output ('main research topics and active projects'). However, it could briefly note that no input is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline score is 4. The description does not need to add parameter semantics since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'main research topics and active projects of the STIL lab'. It is unambiguous and distinguishes from sibling tools like 'get_lab_overview' which covers broader lab information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over siblings (e.g., get_lab_overview, list_publications) or any prerequisites. The description lacks any explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_student_infoCInspect
Get detailed information about a specific student by name (partial match supported).
Args:
name: Student name or partial name to search for
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It only mentions partial match support but omits critical behavior like multiple matches handling, case sensitivity, or error responses.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences and a structured args section. It is front-loaded and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity and presence of an output schema, the description could still be improved by noting behavior on unmatched names or multiple results. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema defines one required parameter 'name' without description. The description adds the context of partial matching, which goes beyond the schema. However, it does not specify format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('get detailed information') and the resource ('specific student'), and notes partial match support, which distinguishes from sibling tools like list_students.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as list_students or get_lab_overview. The description does not specify preconditions or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_publicationsAInspect
List STIL lab publications with optional filters.
Args:
year: Filter by publication year
author: Filter by author name (partial match)
venue: Filter by venue/journal name (partial match)
keyword: Filter by keyword in title
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| venue | No | ||
| author | No | ||
| keyword | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('List') but doesn't explicitly state read-only behavior or any side effects. With no annotations, the description carries the full burden but provides minimal disclosure beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose followed by a bullet list for parameters. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the return structure is covered. The description explains all filters adequately for a straightforward list operation, but could mention default behavior (returns all publications) or combination logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description's one-line explanations for each parameter (e.g., 'Filter by publication year') add necessary clarification. However, it could detail more about parameter interactions or allowed values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List STIL lab publications' with specific verb and resource, distinguishing it from sibling tools that search general repositories (search_arxiv, search_semantic_scholar).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like search_arxiv or search_semantic_scholar. Also lacks prerequisites or context for the filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_studentsAInspect
List students in the STIL lab.
Args:
role: Filter by role — "phd", "master", "intern", or "all"
status: Filter by status — "current", "alumni", or "all"
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | all | |
| status | No | current |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes filtering but omits details like pagination, sorting, authentication requirements, or rate limits. For a straightforward list operation, the minimal description is adequate but not transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose followed by a bullet list for parameters. Every sentence is informative with no fluff. The structure is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. However, it lacks information about edge cases (e.g., empty results) and behavioral traits. For a simple list tool with good sibling differentiation, it is moderately complete but could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, leaving the description to explain parameter meanings. It adds value by listing allowed values for role and status, which are not documented in the schema. However, it does not specify default behaviors beyond what the schema provides via 'default' fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List students in the STIL lab.' This is a specific verb (list) and resource (students in STIL lab), distinguishing it from sibling tools like 'get_student_info' (single student) and 'list_publications' (different resource).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides filtering parameters (role, status) that indicate when to use this tool for broad lists, but does not explicitly say when to avoid it or mention alternative tools. The sibling names imply differentiation, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_arxivAInspect
Search ArXiv for research papers.
Args:
query: Search query — keywords, author name, or topic
max_results: Maximum number of results to return (1–50)
year_from: Only return papers published from this year onwards
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| year_from | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits. It states the tool 'Search[es] ArXiv for research papers', implying a read-only operation, but lacks details on side effects, rate limits, or authentication. The description adds minimal context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief, with one sentence for purpose and a concise list of parameters. Every element serves a purpose; there is no redundancy or filler. It is well front-loaded with the main action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. The description covers parameter semantics and purpose adequately. However, it lacks usage guidelines and fails to mention the tool's limitations or context, keeping it from a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates by explaining each parameter: query as keywords/author/topic, max_results with range (1–50), and year_from as publication year filter. This adds meaning beyond the schema's type and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search ArXiv for research papers', which specifies the verb and resource. The tool name 'search_arxiv' reinforces this. It is distinguishable from siblings like 'search_semantic_scholar' and 'find_related_work' due to the explicit mention of ArXiv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Sibling tools like 'search_semantic_scholar' serve a different database, but the description offers no differentiation or context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_semantic_scholarAInspect
Search Semantic Scholar for research papers (covers ACM Digital Library, IEEE Xplore, and more).
Args:
query: Search query — keywords, topic, or research question
max_results: Maximum number of results to return (1–100)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only includes basic arg info and max_results range. Does not disclose read-only nature, rate limits, or data freshness. For a search tool, more behavioral context needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Efficient, two-sentence main description plus structured args list. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists so return format not needed. Lacks details on sorting, pagination, or error handling. Adequate but not thorough for a search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage; description adds meaningful explanations for both parameters (query type, max_results range). Compensates well for schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'search' and resource 'research papers', covers specific databases like ACM and IEEE, distinguishes from sibling 'search_arxiv'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for comprehensive paper search across multiple databases, but no explicit when-to-use vs. alternatives like search_arxiv or find_related_work.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!