This server acts as an MCP interface to Bunpro, a Japanese grammar/vocabulary SRS platform, letting an LLM agent read study data and manage SRS reviews. It also supports token refresh without restarting the MCP client.
User & Profile
get_user — Retrieve your Bunpro user profile (level, title, settings)
Review Queue & History
get_due_count — Check how many reviews are currently due
get_queue — Fetch the full current review queue
get_reviews — List reviews with pagination
get_last_session — Stats from your most recent review session
get_last_24_hours — Review history for the last 24 hours
Statistics
get_base_stats — Overall study statistics (totals, streaks, etc.)
get_jlpt_progress — Grammar/vocab progress by JLPT level (N1–N5)
get_srs_overview — SRS level distribution across all items
get_srs_level_details — Items at a specific SRS level (1–10) with pagination
get_ghost_details — Ghost review items that reappear after being burned
Forecasts & Activity
get_forecast_daily / get_forecast_hourly — Upcoming daily/hourly review forecasts
get_review_activity — Review activity history (for streak/activity graphs)
Item Details & Search
get_item — Full details for a grammar point or vocabulary item by slug or ID (meaning, structure, examples, SRS status)
get_item_notes — Your personal study notes for a grammar or vocab item
search — Search grammar points and vocabulary by query, with filters for type (grammar/vocab) and result limit
SRS Management
add_to_reviews — Add grammar points or vocab items to your SRS reviews (optionally specifying a deck)
remove_from_reviews — Remove items from your SRS reviews
Bookmarks
add_bookmark / remove_bookmark — Add or remove bookmarks for items
Legacy API (requires BUNPRO_API_KEY)
get_study_queue_legacy — Review queue counts via the legacy API
get_recent_items_legacy — Recently added grammar points via the legacy API
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@bunpro-mcp what's my due count for today?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An unofficial Model Context Protocol server for Bunpro, the Japanese grammar/vocabulary SRS. It exposes Bunpro's review queue, search, statistics, and SRS management as MCP tools, so an LLM agent can read your study data and add grammar points / vocabulary to your reviews.
Disclaimer — please read
This is an independent, unofficial project, not affiliated with, endorsed by, or supported by Bunpro. It wraps Bunpro's private, undocumented frontend API, which can change or break at any time. Built for personal, educational use.
This tool only works because it relies on Bunpro's servers, content, and services. Your use of it — and especially any commercial use — is subject to Bunpro's Terms of Service independently of this project's license. No Bunpro content (grammar explanations, example sentences, vocabulary data, audio) is included in this repository. Use at your own risk. If you build something commercial on top of Bunpro, support Bunpro directly.
Read your review queue, due counts, SRS overview, JLPT progress, forecasts, and session history.
Search grammar points and vocabulary — compact results, filterable by type, size-capped.
Add / remove grammar points and vocabulary to / from your SRS reviews.
Manage bookmarks.
Per-call token resolution: refresh an expired token without restarting your MCP client (see below).
Related MCP server: Anki MCP Server
Node.js 18+ (uses the built-in fetch).
A Bunpro account and its frontend_api_token.
The frontend API uses the frontend_api_token cookie as a bearer token:
Log in to bunpro.jp.
DevTools → Application → Cookies → https://bunpro.jp → copy the value of frontend_api_token.
The token expires roughly monthly; refresh it the same way when calls start returning
401 AUTH_USER_DENIED.
npm install
npm run buildAdd the server to your MCP client config (stdio transport). Build it locally first
(npm install builds via the prepare script), then point at dist/index.js — see
claude_desktop_config.example.json:
{
"mcpServers": {
"bunpro": {
"command": "node",
"args": ["/absolute/path/to/bunpro-mcp/dist/index.js"],
"env": { "BUNPRO_API_TOKEN": "your_frontend_api_token_here" }
}
}
}Not yet published to npm. Once it is, you'll also be able to run it with no local clone via
"command": "npx", "args": ["-y", "@patvandyke/bunpro-mcp"].
BUNPRO_API_KEY (legacy) is optional and only enables the two *_legacy tools.
The token is resolved per request, not just at startup, so a refreshed token is picked up without restarting the server:
BUNPRO_TOKEN_FILE — if set (or, by default, ~/.claude-work/.claude.json when present),
the live BUNPRO_API_TOKEN value is read from that JSON file on each call (30 s cache) and
re-read on a 401. Refresh the token in the file and the next call picks it up — no restart.
This is handy under Claude Code, whose config already holds the token.
Otherwise it falls back to the BUNPRO_API_TOKEN env var supplied at spawn.
A 401 returns a clear "token expired" message instead of dropping the connection.
Tool | Description |
| User profile |
| Number of reviews due |
| Full review queue |
| Paginated reviews |
| Statistics |
| Forecasts & activity |
| History |
| Full detail / notes for one item |
| Search grammar + vocab ( |
| SRS management ( |
| Bookmarks |
| Legacy API-key endpoints |
Frontend API base: https://api.bunpro.jp/api/frontend. Auth: Authorization: Bearer <frontend_api_token>.
The reviews endpoint uses the type names Vocab / GrammarPoint (bookmarks use Vocabulary / GrammarPoint).
Raw search responses can be very large; this server returns a compact projection and reports truncation.
brimalval/bunpro-mcp — an independent Python / FastAPI implementation.
MIT © Patrik Kollár. Keep the copyright / credit notice in copies. This license covers this client code only — it grants no rights to Bunpro's services or content, which remain governed by Bunpro's Terms of Service.
Bookmark a Bunpro item for later review.
| Name | Required | Description | Default |
|---|---|---|---|
| reviewable_id | Yes | ID of the item to bookmark | |
| reviewable_type | Yes | Type of item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic purpose, lacking details on idempotency, error behavior (e.g., if already bookmarked), authentication requirements, or side effects. This is insufficient for safe invocation.
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, 8 words, which is concise but lacks detail. It is front-loaded but at the expense of completeness. Balanced at 3 for being appropriately brief yet underinformative.
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 no output schema and no annotations, the description should explain the tool's role more thoroughly. It omits context like the effect on SRS, reversibility, or what 'later review' means. Covers basic purpose but leaves significant gaps.
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 100%, with both parameters already described in the schema. The description adds nothing beyond what the schema provides, earning the baseline score of 3.
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 phrase 'Bookmark a Bunpro item for later review' clearly states the action (bookmark) and resource (Bunpro item). It distinguishes from siblings like 'remove_bookmark' and 'add_to_reviews' by focusing on bookmarking, which is a unique action.
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 versus siblings such as 'add_to_reviews' (which adds to review queue) or 'remove_bookmark'. The agent is left without context for choosing among related actions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one or more items to your Bunpro SRS reviews. Items start at SRS level 0 and become reviewable immediately. Note: reviewable_type for this endpoint is 'Vocab' or 'GrammarPoint' (not 'Vocabulary').
| Name | Required | Description | Default |
|---|---|---|---|
| reviewables | Yes | Items to add to reviews | |
| deck_id | No | Optional deck ID; null/omitted = default |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that items start at SRS level 0 and become reviewable immediately, and notes the allowed reviewable_type values. However, it omits other behavioral traits such as authentication requirements, side effects, or rate limits.
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 two sentences, front-loaded with core purpose, and includes essential behavioral info without redundancy. Every sentence earns its place.
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?
For a simple mutation tool with 2 parameters and no output schema, the description covers purpose, basic behavior, and parameter nuance. It does not explain return values or error handling, but these are less critical given the tool's straightforward nature.
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 100%, but the description adds value by clarifying the reviewable_type enum values (e.g., not 'Vocabulary') and explaining that deck_id is optional with default behavior. This goes beyond the schema alone.
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 'Add' and the resource 'items to your Bunpro SRS reviews', specifying that items start at SRS level 0 and become reviewable immediately. It also distinguishes from sibling tools like 'remove_from_reviews' and 'get_reviews'.
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 indicates when to use the tool (to add items to reviews) and provides a clarifying note on reviewable_type values ('Vocab' or 'GrammarPoint'). However, it does not explicitly state when not to use or mention alternatives, though the sibling tool list helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get overall Bunpro study statistics (total grammar points, reviews, streaks, etc.).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. It discloses the types of data returned (grammar points, reviews, streaks), but does not mention any potential behavioral traits like caching, auth requirements, or rate limits. Lacks depth on what 'etc.' includes.
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?
A single, front-loaded sentence that efficiently conveys the main purpose and examples. 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?
No output schema exists, so description must cover return values. It lists key statistics but ends with 'etc.', leaving some ambiguity. Given the tool's simplicity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. The description adds value by clarifying what the tool returns, which is beyond the empty schema. It gives concrete examples of the statistics.
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 explicitly states it gets 'overall Bunpro study statistics' and lists examples like total grammar points, reviews, streaks, etc. This clearly distinguishes it from sibling tools that are more specific (e.g., get_due_count, get_jlpt_progress).
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?
It implies usage for general overview but does not explicitly state when to use this tool over 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.
Get the number of reviews currently due in Bunpro.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what the tool does without any details about side effects, real-time behavior, caching, or return format. For a simple count, this is minimal but acceptable; however, it does not go beyond the basic 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 with no unnecessary words. It is front-loaded with the action and resource, achieving maximum conciseness.
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 tool has no parameters and no output schema, the description is adequate but lacks details such as what 'due' means (e.g., which SRS levels). A brief clarification would improve completeness without adding much verbosity.
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 input schema is fully covered by definition. The description does not need to add parameter details, and a baseline score of 4 is appropriate for this case.
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 resource 'number of reviews currently due'. It is specific and distinct from sibling tools like 'get_reviews' (list of reviews) and 'get_base_stats' (general stats), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 it is for a simple count, but it does not differentiate from sibling tools that might also provide due counts, such as 'get_queue' or 'get_study_queue_legacy'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the upcoming daily review forecast (next N days).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose behavioral traits such as read-only nature, data freshness, or what 'forecast' entails (e.g., review counts).
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, front-loaded sentence with no redundant information. It efficiently communicates the tool's 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?
For a zero-parameter tool, the description is adequate but could be more complete by explaining what the forecast contains (e.g., review counts, intervals). With sibling tools, additional context would help.
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 description does not need to add parameter meaning. The schema coverage is 100%, meeting baseline expectations.
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?
Clearly states it gets the daily review forecast for the next N days. The use of 'daily' distinguishes it from the sibling 'get_forecast_hourly'.
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 usage for daily forecasts, but does not explicitly state when to use it versus alternatives like 'get_forecast_hourly' or other review tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the upcoming hourly review forecast for today.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral details beyond being a read operation. No mention of auth needs, rate limits, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, clearly front-loaded with the action and resource.
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?
For a simple tool with no parameters and no output schema, the description is minimally adequate but could be more informative about what the forecast contains (e.g., time slots, review counts).
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 tool has no parameters and the schema is empty, so the description adds no parameter information but also none is needed. The description simply states the tool's purpose.
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 retrieves the upcoming hourly review forecast for today, with a specific verb and resource that distinguishes it from sibling tools like get_forecast_daily.
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 versus alternatives, such as get_forecast_daily. The description does not mention any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ghost review items (items that haunt your review queue after being burned).
| Name | Required | Description | Default |
|---|---|---|---|
| reviewable_type | Yes | Type of reviewable item |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden. It explains the concept of ghost items but does not disclose whether the tool is read-only, requires authentication, or has any side effects. The behavior is implied as a read operation, but lacks explicit 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 sentence that immediately states the core function ('Get ghost review items') and then adds a clarifying parenthetical. It is concise and front-loaded, with no extraneous information.
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?
For a simple tool with one required parameter and no output schema, the description provides the essential concept. However, it omits details about return format, pagination, or how ghost items relate to other review states, leaving gaps in contextual understanding.
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 100% coverage, with the 'reviewable_type' parameter already described as 'Type of reviewable item' and an enum list. The description adds no extra meaning or context for the parameter, so it meets the baseline but does not exceed it.
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's action ('Get ghost review items') and explains the specific concept of ghost items as 'items that haunt your review queue after being burned.' This distinguishes it from other get tools that retrieve active reviews or due counts, though it could be more explicit about the scope.
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 its siblings (e.g., get_queue, get_reviews). There is no mention of prerequisites, context, or alternatives, leaving the agent to infer usage without support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full details for a grammar point or vocabulary item by its slug or ID (e.g. 'は-wa-topic-marking-particle' or '42'). Returns meaning, structure, example sentences, SRS status, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Item slug (e.g. 'は-wa-topic-marking-particle') or numeric ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Lists returned fields but does not disclose error handling, auth needs, or rate limits. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence that front-loads purpose and provides example inputs. No wasted words, but slightly more detail on return type could be added without bloating.
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?
For a simple read tool with one parameter and no output schema, the description covers purpose, parameter, and sample returned fields. Missing behavior on non-existent slug/ID.
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 already describes the single parameter with examples. Description adds examples in context but does not provide additional semantics beyond schema, which has 100% coverage.
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?
Description clearly states verb 'Get' and resource 'full details for a grammar point or vocabulary item', with example inputs. Distinguishes from sibling 'search' by being ID/slug-specific.
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 when slug/ID is known, but does not explicitly state when not to use or mention alternatives like 'search' for fuzzy queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your personal study notes for a grammar point or vocab item.
| Name | Required | Description | Default |
|---|---|---|---|
| slug_or_id | Yes | Item slug or numeric ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states basic action without details on authentication, side effects, or what happens if no notes exist.
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?
Single sentence, directly states purpose without extraneous words. Could be structured with more details but remains efficient.
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?
Adequate for a simple retrieval tool with one parameter. Missing details on return format but not critical given no output schema.
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 covers the single parameter 'slug_or_id' with description. Description adds no extra meaning beyond schema, achieving baseline score.
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?
Description clearly states the verb 'Get', the resource 'personal study notes', and the scope 'grammar point or vocab item'. Distinguishes from siblings like 'get_item' or 'search'.
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 retrieving personal notes for items, but no explicit when-to-use or alternatives compared to siblings like 'get_item'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get grammar/vocab progress broken down by JLPT level (N1–N5).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves progress, but no info on authentication, idempotency, or side effects. Minimal 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with verb, no unnecessary words. Highly concise.
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?
No output schema, and description lacks details on returned data (e.g., counts, percentages, items). Could be more informative given complexity of JLPT levels.
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?
No parameters, so schema coverage is 100%. Description adds no extra semantics about 'progress' or output structure, but baseline for 0 params is 4.
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?
Clearly states verb 'Get', resource 'grammar/vocab progress', and scope 'broken down by JLPT level (N1–N5)'. Distinct from sibling tools like get_base_stats.
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 get_base_stats or get_srs_overview. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get review history for the last 24 hours.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only specifies the time range. It does not disclose whether the tool is read-only, performance characteristics, rate limits, or side effects. Minimal behavioral disclosure.
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 that is clear but very brief. It could be expanded to include more detail without being verbose, achieving a balance between conciseness and completeness.
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 tool has no parameters and no output schema, the description is somewhat complete but could mention what the return format is (e.g., list of reviews) or any limitations. Adequate for a simple query but not fully comprehensive.
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?
No parameters exist, so the baseline is 4. The description adds the constraint of 'last 24 hours', which provides meaningful context beyond an empty schema.
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', the resource 'review history', and the time constraint 'last 24 hours'. It distinguishes itself from siblings like 'get_reviews' (likely all history) and 'get_review_activity'.
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 versus alternatives like 'get_reviews' or 'get_review_activity'. The description offers no context, exclusions, or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get statistics from the most recent review session.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the basic purpose. With no annotations, the description should convey safety, idempotency, or potential side effects. It fails to mention whether it requires a prior session or what happens if none exists.
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 front-loads the key action and resource. Every word serves a purpose, and there is no extraneous information.
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?
For a zero-parameter tool with no output schema, the description provides minimal context. It fails to specify what kind of statistics are returned or the data structure, leaving ambiguity. More detail on the output would improve completeness.
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 schema coverage is 100% by default. The description adds no additional parameter semantics, but with zero parameters, no further elaboration is needed. The baseline of 4 is appropriate.
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 retrieves statistics from the most recent review session, using a specific verb and resource. It distinguishes well from siblings like 'get_last_24_hours' or 'get_reviews'. However, the term 'statistics' is somewhat vague and could be more descriptive.
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 such as 'get_last_24_hours' or 'get_review_activity'. The description lacks any context about prerequisites, typical use cases, or explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full current review queue from Bunpro.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states a read-like operation without disclosing behavioral traits such as authentication requirements, rate limits, or data scope limitations.
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 that is front-loaded and contains no unnecessary words. It is perfectly concise.
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 absence of parameters and output schema, the description is minimal but adequate. However, it lacks detail about the meaning of 'review queue' and what the response contains, which could be important for an agent.
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 tool has no parameters and the schema coverage is 100%. The description does not need to add parameter information, and it is sufficient for an empty schema.
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 retrieves the full current review queue from Bunpro. However, it does not differentiate from sibling tools like get_reviews or get_study_queue_legacy, which may have similar functionality.
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 no guidance on when to use this tool versus alternatives. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recently added grammar points using the legacy Bunpro API key (requires BUNPRO_API_KEY).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Number of recent items to return (1–50) |
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 only notes the authentication requirement but fails to mention safety profile, rate limits, or whether it is a read-only operation. This is insufficient for a tool with zero annotation coverage.
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 that conveys all essential information: the action, the resource, and a key requirement. It is front-loaded and contains no unnecessary words, earning its place efficiently.
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?
For a simple tool with one parameter and no output schema, the description is adequate but could be improved. It explains what it does and the auth requirement, but it does not specify the return format or whether the limit controls pagination, leaving some contextual gaps.
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 100% description coverage for the single parameter 'limit', including defaults and bounds. The tool description adds no additional semantics beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'recently added grammar points'. It distinguishes from sibling tools like get_item or get_reviews by focusing on recent additions and specifying it uses a legacy API key.
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 mentions the prerequisite BUNPRO_API_KEY, implying this tool is for legacy authentication. However, it does not explicitly state when to use this tool over alternatives or when not to use it, leaving usage context implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get review activity history (used for the activity/streak graph).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only states the purpose and does not mention any side effects, authorization requirements, rate limits, or whether the operation is read-only. For a data retrieval tool, this is a significant gap.
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, front-loaded sentence of 10 words. Every word carries meaning, and there is no fluff. It is highly concise and efficient.
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 tool has no parameters and no output schema, the description provides the essential purpose (activity/streak graph). However, it lacks detail about the return format, pagination, or data structure, which would be helpful for an agent to use the output correctly.
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 zero parameters, so schema description coverage is 100%. The description adds no parameter details, but the baseline for 0-param tools is 4, indicating no additional information is needed.
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 uses a specific verb ('Get') and resource ('review activity history'), and includes usage context ('used for the activity/streak graph'). While it distinguishes the tool's purpose, it does not explicitly differentiate it from other get_* tools like get_reviews or get_base_stats, but the graph context provides implicit differentiation.
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 usage for retrieving activity/streak data via the phrase 'used for the activity/streak graph', but lacks explicit guidance on when to use this tool versus alternatives (e.g., get_reviews, get_base_stats) 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 reviews with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number | |
| per_page | No | Results per page |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only mentions pagination, omitting details like sorting, filtering, side effects, or whether it's read-only.
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?
Extremely concise and front-loaded, no wasted words. However, the extreme brevity sacrifices helpful context for the agent.
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?
For a list tool with no output schema and two parameters, the description lacks information about return format, default ordering, or what reviews represent. Among many sibling tools, this is insufficient.
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 100% with descriptions for both page and per_page. The description adds no extra meaning beyond the schema; 'pagination' is redundant with the parameters.
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 lists reviews and supports pagination. It uses a verb and resource, distinguishing it from other list tools by specifying 'reviews', though it could clarify what reviews are in context.
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 versus alternatives like get_item_notes or get_review_activity. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get items at a specific SRS level with pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| level | Yes | SRS level (1–10) | |
| reviewable_type | Yes | Type of reviewable item | |
| page | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes 'with pagination', indicating a behavioral trait beyond the schema. However, it does not disclose read-only nature, auth requirements, rate limits, or behavior when no items exist. Since no annotations are present, the description carries the full burden but only partially fulfills it.
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?
A single sentence that is front-loaded and efficient. However, it could be slightly expanded to include key parameter details without losing conciseness.
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 no annotations, no output schema, and three parameters (one with enum), the description is too sparse. It omits response structure, sorting, and prerequisites, making it incomplete for a tool of moderate complexity.
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 67% (level and reviewable_type have descriptions, page does not). The description adds no extra parameter detail beyond 'with pagination'—it does not explain the 'page' parameter's effect or default value, leaving an ambiguity.
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 it retrieves items filtered by SRS level with pagination, which distinguishes it from siblings like 'get_reviews' or 'get_srs_overview'. However, it omits the reviewable_type filter, which is a key aspect of the tool's purpose.
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 (e.g., 'get_item' for a single item, 'get_reviews' for review history). The description does not mention prerequisites, exclusions, or specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the SRS level distribution — how many items are at each SRS tier.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like read-only nature, safety, or aggregation behavior. It merely states the purpose, not any behavioral implications. The agent cannot infer whether this is a safe, fast operation.
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, front-loaded sentence with no wasted words. It is concise and directly conveys the function.
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 simplicity of the tool (no parameters, no output schema), the description is adequate but could be more specific about the return format. It explains the 'what' but not the 'how' of the data structure. For a tool with no output schema, the description should provide more clarity on the output shape.
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 description has no burden to describe them. The baseline of 4 is appropriate as per the rule for 0 parameters.
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 resource 'SRS level distribution', with further explanation that it returns 'how many items are at each SRS tier.' This distinguishes it from sibling tools like get_srs_level_details which likely provides more granular per-level data.
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 usage guidance is provided. The description does not mention when to use this tool versus other stat tools like get_base_stats or get_forecast_*. It only states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get review queue counts using the legacy Bunpro API key (requires BUNPRO_API_KEY). Returns reviews available now, next hour, and next day.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full responsibility. It discloses that it requires a specific API key, is a read operation, and returns counts for three periods. However, it does not mention rate limits, idempotency, or error conditions.
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?
Single sentence that efficiently conveys the tool's purpose, requirement, and output. No redundancy or fluff.
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?
For a tool with no parameters and no output schema, the description fully covers what the agent needs: what it does, what it requires, and what it returns. Minimal complexity means minimal description suffices.
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 zero parameters, and the schema coverage is 100%. Per guidelines, baseline is 4. The description adds value by explaining the output structure (now, next hour, next day) even though no parameters 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?
Clearly states the verb 'get', resource 'review queue counts', and specifies it uses the legacy Bunpro API key. It also describes the return values (now, next hour, next day), differentiating it from other tools.
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?
Explicitly mentions the prerequisite BUNPRO_API_KEY. While it doesn't compare directly to siblings, the 'legacy' label implies context. The description of returned time frames helps the agent decide when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current Bunpro user profile (level, title, settings).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it retrieves data, which implies a read-only operation. Does not disclose any side effects, authentication needs, rate limits, or return format. Minimal but not misleading.
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?
Single sentence, front-loaded, and efficient. Every word adds value; no wasted space.
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 no output schema, the description adequately covers purpose and key fields. Could clarify that 'current' refers to the authenticated user, but not essential for this simple 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?
No parameters, schema coverage 100% (empty). Baseline 4 applies; description adds no parameter info because none exist. No need for additional detail.
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?
Description uses a specific verb 'Get' and resource 'current Bunpro user profile', listing three fields (level, title, settings). It clearly distinguishes from sibling tools like get_base_stats or get_item by targeting the user profile specifically.
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 explicit guidance on when to use this tool versus alternatives. Usage is implied from the description: to retrieve the current user's profile. Lacks when-not or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove a Bunpro bookmark by its bookmark ID.
| Name | Required | Description | Default |
|---|---|---|---|
| bookmark_id | Yes | Bookmark ID to remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits like irreversibility, preconditions, or side effects. This is a significant gap for a deletion tool.
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?
One sentence, front-loaded, with no wasted words. Perfect efficiency.
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?
For a simple one-parameter delete operation with no output schema, the description is nearly complete. It could mention permanence or error scenarios, but not required for minimal completeness.
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 100% (bookmark_id has a description). The description adds no extra meaning beyond the schema, so baseline 3 applies.
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 (remove), the resource (Bunpro bookmark), and the method (by bookmark ID). It directly distinguishes from sibling tools like add_bookmark and remove_from_reviews.
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 when to use (when you need to remove a bookmark by ID) but does not provide explicit when-not-to-use or alternative suggestions. For a single-purpose tool, this is minimal but acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove one or more items from your Bunpro SRS reviews.
| Name | Required | Description | Default |
|---|---|---|---|
| reviewables | Yes | ||
| deck_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'remove' without disclosing effects like permanence, side effects on SRS, or required permissions. It lacks 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded and contains 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?
Without output schema or annotations, the description is brief and does not cover what happens after removal, error conditions, or return values. It is minimally adequate for a simple mutation 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 description does not explain parameters beyond the schema structure. 'One or more items' aligns with the array requirement, but deck_id and reviewable structure are not elaborated. Schema coverage is 0%, so description adds minimal value.
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 'Remove' and resource 'items from your Bunpro SRS reviews'. It distinguishes from siblings like 'add_to_reviews' and 'remove_bookmark' by specifying the review context.
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 such as 'remove_bookmark' or 'add_to_reviews'. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Bunpro grammar points and vocabulary. Returns compact matches (id, title, kana, level, meaning) plus a truncated field when results were capped. Use the grammar/vocab flags to narrow the search and limit to cap each section (raw payloads can exceed 240 KB). Get full per-item detail via get_item.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query (e.g. 'は', 'て-form', 'must') | |
| grammar | No | Include grammar points in results | |
| vocab | No | Include vocabulary in results | |
| limit | No | Max results returned per type (grammar / vocab) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses return format (compact matches with truncated field) and warns about large payloads (240 KB). It does not explicitly state read-only nature but it is implied.
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?
Three sentences, front-loaded with purpose, no wasted words. Efficient and well-structured.
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?
No output schema, but description explains return fields and truncated behavior. Adequately covers search tool needs given parameter count and sibling context.
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 100%, so parameters are already described. The description reinforces usage of grammar/vocab flags and limit but adds minimal new semantics beyond schema descriptions.
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 searches Bunpro grammar points and vocabulary, specifies the return fields, and distinguishes from the sibling tool get_item by advising to use it for full detail.
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 guidance on using flags to narrow search and limit to cap sections, and advises using get_item for full per-item detail. It does not explicitly state when not to use this tool but context makes it clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0add_bookmarkadd_to_reviewsget_base_statsget_due_countget_forecast_dailyget_forecast_hourlyget_ghost_detailsget_itemget_item_notesget_jlpt_progressget_last_24_hoursget_last_sessionget_queueget_recent_items_legacyget_review_activityget_reviewsget_srs_level_detailsget_srs_overviewget_study_queue_legacyget_userremove_bookmarkremove_from_reviewssearchMost tools have clearly distinct purposes, but there is some overlap between queue-related tools (get_due_count, get_queue, get_reviews, get_study_queue_legacy) and between list-based statistics (get_last_24_hours, get_review_activity). Descriptions help differentiate, but an agent might occasionally misselect.
All tool names follow a consistent snake_case verb_noun pattern (e.g., add_bookmark, get_due_count, remove_from_reviews). Legacy tools are suffixed with _legacy. No mixing of conventions or ambiguous verbs.
23 tools cover the main aspects of the Bunpro study platform (user, items, reviews, SRS, bookmarks, statistics) without being excessive. Each tool serves a specific function and feels well-scoped.
The tool surface covers core workflows: searching, viewing item details, managing reviews, bookmarks, and statistics. A minor gap is the absence of a tool to update personal notes (only get_item_notes exists), but general CRUD operations for items are not needed for a study app.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
The OpenRouter MCP server plugs OpenRouter into the AI tools you already use. Once connected, your assistant can pull live OpenRouter data (models, prices, your credits, rankings, and docs) and send quick test messages, all without leaving your editor.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/PatVandyke/bunpro-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
