academic-workflow-mcp

by wuruiqi

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.2.0
Disambiguation5/5
Each tool targets a distinct step in the academic workflow, from importing and retrieving papers to writing notes, syncing highlights, and managing duplicates. There is no functional overlap; the descriptions clearly delineate their purposes.
Naming Consistency5/5
All tool names follow the 'workflow_verb_noun' pattern consistently, using snake_case throughout. The verbs (get, write, list, attach, confirm, etc.) are descriptive and follow a predictable structure.
Tool Count5/5
With 10 tools, the server is well-scoped for its domain of academic literature management. Each tool covers a necessary aspect of the workflow, and the count is neither too few nor excessive.
Completeness4/5
The tools cover the full lifecycle from import to review, including duplicate detection and syncing. Minor gaps exist, such as the lack of a dedicated tool to update note content in-place (though write_note with overwrite partially addresses this). Overall, an agent can accomplish most tasks without dead ends.
Average 4.5/5 across 10 of 10 tools scored. Lowest: 3.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- Last stable release on June 28, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses read-only nature and return schema but lacks details on auth, rate limits, or error handling. Since no annotations exist, additional behavioral context would be beneficial.
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?
Concise, front-loaded, every sentence adds value. Args and returns clearly formatted with no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, usage, parameter, and return format adequately for a simple read tool. Minor missing details like behavior on missing notes are implied by the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description fully explains the sole parameter 'citekey' as a Better BibTeX citekey equivalent to filename without .md, which is critical given 0% schema description coverage.
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?
Clearly describes reading a literature note from Obsidian vault with specific verb and resource. Could explicitly differentiate from siblings like workflow_write_note, but the context is sufficient.
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?
Provides use cases (review, check status, decide overwrite/patch) but does not explicitly state when not to use or name alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the character limit (≤200 chars), the linking behavior to Obsidian, and the return format. However, it does not discuss error handling, side effects, or rate limits. It adequately covers the main behavioral traits but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with distinct sections: one-sentence purpose, requirements, parameter list with helpful notes, and return format. Every sentence adds value without redundancy.
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 5 parameters, no output schema, and no annotations, the description is largely complete. It explains all parameters, return format, and prerequisites. Minor gaps include not clarifying what a 'child note' is in Zotero or constraints on the Obsidian link, but overall it provides sufficient context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must fully explain parameters. It does so effectively: item_key is '8-char Zotero internal key', citekey is 'Better BibTeX citekey for obsidian link', summary is 'one-sentence, ≤150 chars', rating defaults to '⭐⭐⭐', and cite_in is 'grant/paper section'. This adds substantial meaning beyond the schema's titles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a short child note (≤200 chars) under the Zotero item that links back to the Obsidian deep note.' This is a specific verb+resource with scope (short child note, linking to Obsidian), and it distinguishes the tool from siblings like workflow_get_note and workflow_write_note.
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 mentions required environment variables (ZOTERO_API_KEY, ZOTERO_LIBRARY_ID) and lists arguments, which provides some usage context. However, it does not explicitly state when to use this tool versus alternatives (e.g., workflow_write_note for longer notes) 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains the title extraction method (metadata then largest-font text), deduplication logic (skip identical file, attach to existing metadata-only entry), and storage copying behavior. It does not cover error handling or rate limits, but the provided details are substantial and clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with numbered improvements, Args, and Returns sections. It front-loads the main purpose and key features. While slightly lengthy, every part contributes value and the organization helps readability.
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 0% schema coverage and no output schema, the description provides a detailed return structure and explains all parameters. It covers the core behavior (title extraction, deduplication, storage) and return value fields. Missing details like error handling for invalid paths are minor; overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by listing parameters in the Args section with context: pdf_paths (absolute paths), collection (exact case-sensitive, empty for root), and item_type (default 'preprint', with example values). This adds meaning beyond the schema's type and default fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it imports PDFs into Zotero with automatic title extraction and smart deduplication. It distinguishes itself from a related tool (zotero_add_from_file) by listing specific improvements, and sibling tool names indicate different workflows, making its unique purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear context for when to use the tool (importing PDFs) and mentions improvements over zotero_add_from_file, but it does not explicitly guide the agent on when not to use it or how it compares to sibling tools like workflow_get_paper or workflow_find_duplicates. The usage guidelines are 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the write operations (updating Obsidian and Zotero) and the return structure, compensating for absent annotations. Lacks details on error handling or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise and well-structured with an Args section, but slightly verbose with default values repeated in both the description and schema.
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?
Covers the action, all parameters with defaults, and return format exhaustively, making it fully self-contained for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds full meaning for all four parameters, including types and defaults, citing specific examples like 'Better BibTeX citekey' and tag defaults with translations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it marks a literature note as reviewed by updating Obsidian frontmatter and Zotero tags, using specific verbs and resources. This distinguishes it from sibling workflow tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states to call only after human review and approval, providing clear when-to-use guidance. However, it does not mention alternatives or when not to use.
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?
Describes that it scans entire library if collections empty, uses title threshold, and returns grouped duplicates with suggested keep. No annotations provided, but description covers key behavioral aspects for a scan tool.
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?
Concise, front-loaded purpose, efficient use of words. Includes detailed return structure despite no output schema. No 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?
Provides return value structure, input semantics, and usage context. Sibling tool names indicate this is the only duplicate finder, so completeness is high.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but description fully explains both parameters: collections (names or empty for all) and title_threshold (word-overlap ratio, default 0.85, effect of lower values). Adds significant meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it scans Zotero for duplicate items by DOI or similar title. Distinct from sibling tools which deal with notes, papers, and imports.
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?
Explicitly advises running before a reading session or after batch import to prevent duplicate annotation work. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It details the return structure including a 'found' bool and possible empty fields ('fulltext may be empty'). No contradictions, but could mention error handling or performance traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose, then usage, parameters, and return format. Every sentence earns its place; no redundancy. Ideal balance of detail and brevity.
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 one parameter, no output schema, but rich return format described with sample JSON. Covers all needed info for analysis: metadata, fulltext, annotations, existence flags. Adequate for an LLM to use effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'identifier' lacks schema description (0% coverage), but the Args section adds rich meaning: examples (Zotero key, citekey, DOI, title keywords) far exceed schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Retrieve' and resource 'everything needed to analyze a paper' including metadata, full text, and PDF annotations. Explicitly positions as first step before generating a literature note, distinguishing it from sibling tools like workflow_get_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context: 'Use this as the first step before generating a literature note.' While it does not list alternatives or when not to use, the context is clear and sufficient for guiding the agent.
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?
No annotations are provided, so the description bears full responsibility. It details the destructive actions (deleting Obsidian notes, trashing Zotero items) when auto_apply=True, and the safe dry-run mode. It does not mention authorization or rate limits, but the behavioral effects are sufficiently covered.
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 well-organized with headings, bullet points, and a clear argument specification. Each sentence is informative, and the structure aids readability. It is appropriately sized for the tool's complexity.
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 complexity of a bidirectional sync check with multiple sub-checks and side effects, and no output schema, the description provides a comprehensive explanation. It details all three direction modes, dry-run vs. auto_apply behavior, and the return structure in a pseudo-JSON format, making it complete for an agent to use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully carries the burden. It clarifies the allowed values for 'direction' (trash_to_obs, obs_to_zotero, both) and explains the effect of 'auto_apply' (report only vs. actually delete/trash), adding critical meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Bidirectional sync check between Zotero and Obsidian' and enumerates three specific direction modes. It distinguishes itself from sibling tools like workflow_attach_zotero_note and workflow_sync_highlights by focusing on sync consistency rather than note creation or highlight synchronization.
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 explains when to use each direction (trash_to_obs, obs_to_zotero, both) and explicitly warns about the dry_run default and the need to review output before setting auto_apply=True. However, it does not explicitly contrast with sibling tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full weight and delivers: it explains the optional cross-check, the performance impact of check_notes ('Slower when True'), and the precedence rule ('collection takes precedence over tag'). It also discloses the default limit and the return format including note_status. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a concise opening sentence, a usage line, and clearly labeled Args/Returns sections. Every sentence adds value; no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (interaction with Zotero and Obsidian, 4 parameters, no output schema), the description covers the return format and parameter behavior well. However, it does not mention prerequisites (e.g., API keys) or error handling, which could be useful for completeness. Still, it is largely adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so thoroughly: each parameter is explained with examples (e.g., '待读' or '#待读'), default values, precedence rules, and the effect of check_notes. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a clear verb-resource pair: 'List papers from Zotero'. It specifies filtering by tag or collection, and an optional cross-check with Obsidian. This distinguishes it from sibling tools like workflow_get_paper (single paper retrieval) and workflow_sync_highlights (highlight syncing).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states usage: 'Use this to build a reading queue or to identify papers that still need to be processed.' This provides clear context. It does not, however, mention when not to use it or compare directly with siblings, but the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It discloses key behaviors: it replaces existing highlight content, leaves metadata untouched, and returns a JSON with success, count, and message. This level of detail adequately informs an agent of side effects and safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It opens with a clear one-sentence purpose, followed by usage guidance, then a structured Args section with brief but sufficient definitions, and finally a Return type description. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 2 simple parameters, no output schema, and no annotations, the description covers the core behavior, parameter semantics, and return format. It could be slightly more explicit about prerequisites (e.g., Zotero and Obsidian connection) and the fact that this is a write operation, but overall it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description fully compensates. It defines 'citekey' as 'Better BibTeX citekey (used to locate the Obsidian note)' and 'item_key' as 'Zotero internal item key (needed to fetch annotations).' This adds crucial meaning beyond the parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Pull PDF annotations from Zotero and update the 'Highlights from Paper' section of the corresponding Obsidian literature note.' It uses a specific verb ('pull', 'update') and resource ('PDF annotations', 'Obsidian literature note'), and this purpose is distinct from sibling tools like workflow_sync_check or workflow_write_note.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'Run this any time after you have highlighted the PDF in Zotero.' It also clarifies behavioral constraints: 'Existing highlight content is replaced; metadata sections are untouched.' However, it does not explicitly state when not to use the tool or mention alternatives, though the specific workflow context makes the guidance clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully carries the burden. Discloses file location, YAML frontmatter, status 'pending-review', placeholder handling for omitted sections, overwrite semantics, and return value structure. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with separate paragraphs for overall behavior, then Args and Returns. Concise without unnecessary fluff. Could be slightly tighter but is effective.
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 no output schema, description includes return type and structure. Covers all parameters, behavior, workflow with sibling tool reference. Nested objects are sufficiently detailed. No gaps for a write tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% but description thoroughly explains each parameter: citekey as Better BibTeX key (filename), metadata with expected keys (title, authors, year, journal, doi, zotero_link), sections with recognized keys and placeholder behavior, overwrite with default false. Adds meaning beyond schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'write' and the resource 'structured literature note', with specific location '10-Literature/<citekey>.md' and mention of YAML frontmatter and section headings. Distinguishes from sibling tools like workflow_get_note and workflow_attach_zotero_note by focusing on note creation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: note is created with status 'pending-review' and instructs to call workflow_confirm_review after human checks. Also explains overwrite behavior to avoid clobbering. Lacks explicit 'when not to use' but provides clear workflow context.
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:

[![zo-bridge MCP server](https://glama.ai/mcp/servers/wuruiqi/zo-bridge/badges/card.svg)](https://glama.ai/mcp/servers/wuruiqi/zo-bridge)

Score Badge

Copy to your README.md:

[![zo-bridge MCP server](https://glama.ai/mcp/servers/wuruiqi/zo-bridge/badges/score.svg)](https://glama.ai/mcp/servers/wuruiqi/zo-bridge)

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/wuruiqi/zo-bridge'

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