bit101-mcp

by tiny-paris

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation4/5
Each tool maps to a distinct resource or time range, and the schedule tools are explicitly qualified as today, week, or whole term. The only mild overlap is between search_courses and get_course_reviews, but the descriptions help differentiate them.
Naming Consistency5/5
Tool names consistently use a verb prefix (get, list, or search) followed by a lowercase snake_case noun phrase, such as get_course_reviews and list_today_posts. There is no mixed casing or inconsistent verb style.
Tool Count5/5
Ten tools cover the main BIT101 areas—posts, courses, schedules, grades, and tasks—without feeling bloated. The additional schedule and post tools each serve a specific retrieval need, so the count is well-scoped.
Completeness4/5
The read-only surface is fairly complete for posts, courses, schedules, scores, and Lexue tasks. Minor gaps exist, such as arbitrary future-date schedule lookup and any write/submit endpoints, but these are likely outside scope and workarounds are available.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful context that this is an aggregating read operation pulling several data categories, but it does not disclose details such as pagination behavior, rate limits, or the reach of 'historical score data'.
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 compact sentence front-loads the action and lists the key result categories with no filler or redundancy. Every word contributes to understanding what the tool returns.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With read-only annotations, a full output schema, and fully documented parameters, the description is largely sufficient for an agent to invoke the tool correctly. The main gap is the lack of guidance for choosing this tool over sibling tools, though that is more a usage-rule concern than a completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both course_id and comment_pages are already well documented with types, defaults, and bounds. The description adds no additional parameter-specific meaning, so it meets the baseline without exceeding it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('aggregate') and enumerates the returned resources ('course metadata, teachers, reviews, and historical score data'), making the tool's focus clear. It does not explicitly contrast with siblings like search_courses or get_scores, but the resource description is sufficiently unambiguous.
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 about when to use this tool versus sibling tools such as search_courses, get_post, or get_scores. The description only states what it aggregates, leaving the agent to infer appropriate usage from the tool name and title.
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 description is not burdened with explaining safety behavior. It adds some scope context (courses and teacher records) but does not disclose additional behavioral traits such as matching behavior or ordering semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with no filler. It is front-loaded with the verb and target resource and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema, annotations, and parameter descriptions, the definition is largely complete for a search operation. The only notable gap is the absence of any usage guidance relative to sibling tools, but this does not prevent an agent from invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 75%: query, page, and limit have descriptions, and order has an enum. The description adds little beyond what the schema already says, though it does reinforce that queries can target both course and teacher records.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb and resource: 'Search BIT101 course and teacher records.' This identifies the tool's scope and distinguishes it from siblings like search_posts, though it does not explicitly contrast itself with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as search_posts or get_course_reviews. The resource scope is implied by the description, but no when-to-use or when-not-to-use context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations already present, the description still adds value by warning that invalid subscriptions can reopen browser setup and instructing not to retry. This exposes an important side effect beyond the standard 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 one compact, front-loaded sentence: purpose first, then the critical retry warning. Every phrase earns its place with no filler.
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 single-parameter read-mostly tool with an output schema, the description covers the core action and the critical failure behavior. It could be more complete by explicitly saying the result is a list of upcoming Lexue tasks, but the name, title, and days parameter fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the only parameter, days, with a clear description ('Future time window in days'), so schema description coverage is 100%. The prose description adds no parameter-level detail, matching the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a concrete action ('Return Lexue events') and the tool name/title specify 'upcoming Lexue tasks', which separates it from the post/course/schedule siblings. It is slightly vague because the description says 'events' rather than 'tasks' and does not explicitly mention the upcoming time window beyond the days parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no when-to-use guidance or comparison with sibling tools like get_today_schedule or list_today_posts. The only usage-related note is 'do not retry', which is a retry prohibition rather than guidance for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, covering the safety profile. The description adds useful context with 'when available' and the operational note 'browser: do not retry,' but the browser note is terse and does not explain failure or retry semantics in detail.
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 behavior first. The 'browser: do not retry' clause is terse but adds an operational constraint without 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?
For a no-parameter, read-only tool with an output schema, the description is nearly complete: it states what is returned and that class average/maximum may not always be present. The ambiguous 'browser: do not retry' note prevents a perfect completeness score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and schema description coverage is 100%, so there is no parameter information the description needs to add. The baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Return grades' with an added detail about class average/maximum. This clearly identifies the tool's purpose and distinguishes it from the schedule, course, and post-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance about when to use this tool versus alternatives, and no prerequisites or exclusions are stated. The name implies the use case, but the description does not actively help an agent decide between tool options.
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 mark the tool as readOnlyHint=true, covering the safety profile. The description adds minimal behavioral detail beyond this, but for a simple single-ID read operation, the core behavior is adequately conveyed. No hidden side effects or 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, front-loaded sentence with no filler. It communicates the action, the resource, and the selection criterion efficiently.
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 simple get-by-ID tool, the description, input schema, output schema, and annotations provide everything an agent needs to invoke it correctly. No additional context about return values or safety is necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents post_id with its own description, so schema coverage is 100%. The description adds no additional parameter semantics beyond what the schema already provides, fitting the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Return') and a specific resource ('one BIT101 post') with a precise selection mechanism ('by ID'). This clearly distinguishes it from sibling list/search tools and leaves no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the proper usage: call this tool when you have a specific post_id and need exactly one post. However, it does not explicitly state when to use this tool instead of list_today_posts or search_posts, nor does it mention alternatives.
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, covering the operation's safety and dynamic nature. The description adds the 'public' scope and 'discussion posts' resource, which is useful context, but does not disclose additional behavioral details such as pagination behavior, result ordering, or real-time semantics beyond what annotations and schema already provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It conveys the essential purpose immediately and does not repeat information already available in the schema or annotations.
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 simple search tool with three well-documented parameters, readOnly/openWorld annotations, and an output schema, the description is sufficient. An agent can correctly understand the tool's purpose and invoke it without needing additional context.
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 provides complete descriptions for all three parameters (query, page, limit), so the description does not need to compensate. The description itself adds no parameter-level meaning, but with 100% schema coverage the 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 specific verb 'Search' and the resource 'public BIT101 discussion posts,' making the tool's purpose immediately evident. It distinguishes itself from sibling tools like list_today_posts and get_post by emphasizing search over listing or retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for searching public posts by keyword, but it does not explicitly state when to use it instead of alternatives like list_today_posts or get_post. There is no exclusionary guidance or mention of alternatives, so the agent must infer usage from the name and description.
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, so the safety profile is covered. The description adds genuinely useful behavior beyond annotations: 'browser may open' and 'do not retry'. Nothing contradicts the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences carry purpose, output character, a side-effect warning, and a retry instruction with no filler. The most important routing information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single optional parameter, an output schema, and read-only/open-world annotations, the description covers what to call, what kind of output to expect, and the notable side effect. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so week_offset is fully documented with its default, range, and meaning. The description only paraphrases this/next/last week and adds no parameter-specific details, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (a relative week's BIT schedule) and the action (get/call for this/next/last week), so an agent can tell what the tool does. It does not explicitly contrast with siblings like get_today_schedule or get_schedule, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call for this/next/last week' provides a clear target use case, and 'do not retry' gives explicit invocation guidance. It lacks exclusions or named alternatives, such as pointing to get_today_schedule for today-only schedules, so it is not a 5.
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, covering safety and world-openness. The description adds the non-obvious behavioral constraint 'Whole term only' and the retry guidance, which go beyond the structured metadata. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short clauses, each carrying distinct functional or operational information. It is front-loaded with the core scope ('Whole term only') and has no filler or 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 single optional parameter, full schema coverage, an output schema, and annotations covering safety, the description provides the remaining necessary context: scope, sibling routing, and a retry caveat. Nothing essential is missing for correct tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single optional 'term' parameter, including its format, default, and example. The description does not add parameter-level detail, but with 100% schema 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.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The title 'Get BIT schedule' and description 'Whole term only' make it clear the tool retrieves a schedule for a full term, distinguishing it from week-based schedule tools. It lacks an explicit verb in the description, but the name and title supply the action and resource.
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 states when to use this tool ('Whole term only') and directs users to a specific alternative ('for relative weeks use get_week_schedule'). It also adds the operational warning 'browser: do not retry', which is useful guidance for invocation.
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 a concrete behavioral warning beyond the annotations: it may open a browser for school login, and the agent should wait and not retry. This is valuable context that readOnlyHint/openWorldHint do not fully convey. The instruction 'wait, do not retry' is slightly ambiguous, preventing a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core purpose is front-loaded, and the critical runtime warning follows immediately. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are no parameters, an output schema exists, and annotations already cover read-only and open-world behavior, the description is complete for selecting and invoking the tool. The only behavioral nuance an agent needs—possible browser opening and no retry—is explicitly stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema covers 100% of them, so there are no parameter semantics the description needs to explain. The baseline of 4 for a zero-parameter tool 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 states a specific verb ('Return') and a precise resource ('today's classes'), making the tool's scope immediately clear. It also naturally distinguishes this tool from siblings like get_week_schedule and get_schedule by anchoring on 'today's'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving today's classes, but it never explicitly states when to use it versus alternatives such as get_week_schedule or get_schedule. The browser/login warning is behavioral guidance, not usage selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description reinforces this by saying 'Return'. It adds valuable context about the Asia/Shanghai timezone determining the day boundary. No contradictory or misleading behavior is stated, and the description does not claim anything beyond what the tool does.
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 that front-loads the purpose, resource, and timezone. Every word is necessary and there is no extraneous information.
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 simple read-only list operation with zero required parameters and an output schema present, the description fully covers the essential contextual detail: the resource, the time scope, and the timezone boundary. Nothing critical for invoking this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the only parameter 'limit' is fully documented in the schema as 'Maximum posts to return' with defaults and bounds. The description does not add additional parameter behavior beyond what the schema already provides, so the 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 states a specific verb ('Return'), a clear resource ('BIT101 posts'), and an unambiguous scope ('created today in Asia/Shanghai time'). It distinguishes itself from siblings like search_posts and get_post by focusing on today's posts. The addition of the timezone disambiguates the meaning of 'today'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly communicates that this tool returns today's BIT101 posts, implying it is the choice when the agent needs a list of posts from the current day in Asia/Shanghai time. It does not explicitly name alternatives or exclusion conditions, but the context is clear enough relative to siblings such as search_posts and get_post.
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:

[![BIT101-mcp MCP server](https://glama.ai/mcp/servers/tiny-paris/BIT101-mcp/badges/card.svg)](https://glama.ai/mcp/servers/tiny-paris/BIT101-mcp)

Score Badge

Copy to your README.md:

[![BIT101-mcp MCP server](https://glama.ai/mcp/servers/tiny-paris/BIT101-mcp/badges/score.svg)](https://glama.ai/mcp/servers/tiny-paris/BIT101-mcp)

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/tiny-paris/BIT101-mcp'

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