joplin-mcp

by johnsarie27

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.3.1
Disambiguation5/5
Each tool has a clear, distinct purpose. Note operations (create, delete, get, update, search) are separate from notebook list, tag list, and todo status. There is no ambiguity between similar tools like list_notes_in_notebook and search_notes, as they operate differently.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern (e.g., create_note, list_notebooks, complete_todo). Verbs are descriptive and uniform, with no mixing of styles like camelCase or inconsistent prefixes.
Tool Count5/5
10 tools is well-scoped for a note-taking service. It covers core note operations (CRUD plus search), notebook listing, tag listing, and todo completion without being excessive or sparse.
Completeness4/5
The tool set covers essential note lifecycle operations and adds tag and notebook listing. A minor gap is the lack of a global 'list all notes' tool (only list by notebook or tag, and search by keyword). Otherwise, the surface feels complete for typical usage.
Average 3.7/5 across 9 of 10 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 33 commits in the last 12 weeks
- Last stable release on July 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the output but does not disclose behavioral traits such as case sensitivity, search scope (title vs. body), pagination, sorting, or read-only nature. The description is too minimal for an agent to infer safe usage.
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 very concise with two sentences covering purpose and output. However, it could be improved by adding a brief note on parameter usage without becoming verbose. Currently it is efficient but lacks depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the large set of sibling tools and the absence of parameter descriptions in the schema, the description is insufficient. It does not differentiate this search from other retrieval tools, nor does it explain behavior beyond basic output. An output schema exists but is not described in the tool description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage. The tool description only mentions 'by keyword', which relates to the 'query' parameter, but does not explain the 'limit' parameter or its default value. The description adds some meaning for query but is incomplete.
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 that the tool searches Joplin notes by keyword and returns note titles and IDs. This distinguishes it from sibling tools like get_note (single note) or list_notes_in_notebook (filtered by notebook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. For example, it does not clarify that this tool is for keyword-based search while filtering by notebook or tag requires other tools. No exclusions or context are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the failure condition (fails if not a to-do) which is a key behavior. However, it does not mention idempotency, authorization requirements, or side effects (e.g., whether changing completed to false undoes completion). Basic transparency, but gaps remain.
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?
Extremely concise (one sentence) and front-loaded with the main action. Includes a critical failure condition. However, it could be structured slightly better (e.g., separating parameter info), but no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 2 parameters, no annotations, and an output schema (not shown), the description lacks return value info, idempotency, and prerequisites. Sibling tool exists but no comparison. The description is too minimal to fully guide correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description does not elaborate on parameters beyond the action. It does not explain that note_id identifies the note or that completed defaults to true. The description adds no semantic value over the raw schema, leaving the agent to guess parameter roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (mark), resource (to-do note), and the two states (complete/incomplete). Also mentions failure condition for non-to-do notes, which distinguishes it from a generic update tool. Sibling get_note is for retrieval, so purpose is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies usage for toggling completion status but provides no explicit when-to-use or when-not-to-use guidance. No mention of alternatives or exclusion cases beyond the failure condition. Sibling get_note is not referenced, so the agent must infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states that deletion moves the note to Joplin's trash rather than permanently deleting it. This is a key behavioral disclosure beyond the parameter schema. No annotations are provided, so the description carries full responsibility for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that front-load the core action ('Delete a note by its id') and then add a crucial nuance (trash vs. permanent delete). No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter, the description is mostly sufficient. However, given the presence of sibling tools like 'complete_todo' and 'update_note', it lacks guidance for choosing this tool over those. It also does not explain the return value, but an output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description merely says 'by its id', which adds no insight beyond the parameter name. It does not explain what a valid note_id looks like, how to obtain one, or any constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'delete' and the resource 'note by its id'. This distinguishes it from sibling tools like 'create_note', 'update_note', and 'get_note', which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'complete_todo' for todo notes or 'update_note' for modifications. The description only mentions trash behavior, which is a behavioral trait, not a usage criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states 'Create a new note' which implies non-destructive, but lacks details on side effects, limits, or return behavior. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that efficiently convey the core purpose and a key prerequisite. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (3 required params, no nested objects) and output schema exists, so completeness is moderate. However, lack of parameter descriptions and behavioral details leaves gaps that the description could fill.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but description adds no meaning beyond parameter names. Only mentions notebook_id in context of finding it via list_notebooks. Title and body are left entirely to inference from names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Create' and resource 'new note in the given notebook'. Distinguishes from sibling tools that perform other operations (delete, get, search, update, etc.).
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 suggests using list_notebooks to find the required notebook_id, providing clear guidance on a prerequisite. No explicit when-not-to-use, but the tool is self-contained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states a basic function, omitting details like pagination, sorting, limit behavior, or what happens when no notes match. The limit parameter is not explained, leaving the agent uninformed about result set handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with no unnecessary words. The main action is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values need not be described. However, with 2 parameters (1 required), no schema descriptions, and no behavioral details from annotations, the description is somewhat thin. It covers the essential tag_id lookup but lacks information on limit usage, result ordering, or edge cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should clarify parameter meanings beyond the schema. It mentions tag_id implicitly ('use list_tags to find a tag_id') but does not explain the limit parameter or provide format constraints or examples. The description adds minimal value over 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 the tool's purpose: 'List notes with a given tag.' It specifies the action (list), resource (notes), and filtering criterion (tag). It also directs to list_tags for tag discovery, differentiating it from sibling tools like list_notes_in_notebook and search_notes.
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 usage guidance by referencing list_tags to find a tag_id, which is helpful context. However, it does not explicitly state when not to use this tool or mention alternative tools for other scenarios, missing an opportunity to guide against misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states it updates fields; doesn't disclose side effects, permissions, idempotency, or behavior on missing note_id. Lacks critical behavioral context for a mutation 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?
Two short, direct sentences. Front-loaded with verb and resource, then clarifies partial update. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 3-param tool with output schema, the description is adequate but lacks details on error handling, return value, or prerequisites. Not fully complete given the context signals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning by explaining partial update semantics for title and body, but doesn't describe note_id or parameter types beyond high-level intent.
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 'Update' and resource 'existing note', specifies which fields are affected ('title and/or body'), and distinguishes from siblings like create_note and delete_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?
Implicitly indicates when to use: to modify an existing note's content. The phrase 'Only provided fields are changed' guides on partial updates, but no explicit when-not or alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation ('fetch') but no annotations are provided. It lacks details on permissions, rate limits, or what 'full content' specifically includes, though an output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous words, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with an output schema, the description adequately conveys the core action without requiring additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for note_id, and the description only says 'by its id', adding minimal semantic value beyond the parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'fetch' and the resource 'full content of a single Joplin note by its id', distinguishing it from siblings like create_note or update_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 implies usage when you have a note_id and want full content, but does not explicitly state when to use this tool versus search_notes or update_note.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It indicates a read operation (list) but does not confirm side effects, auth requirements, error handling, or pagination beyond the limit parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no redundant information. The first sentence states the purpose, the second provides a helpful pointer. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the need to describe return values is reduced. The description covers the core purpose and a prerequisite (getting notebook_id). It lacks notes on ordering or error cases, but is adequate for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must add meaning. It explains notebook_id context ('Use list_notebooks to find a notebook_id') but provides no details on the 'limit' parameter. Partial compensation for one of two parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List notes in a notebook') and distinguishes from search tools by specifying 'without a search query'. It also provides a pointer to list_notebooks for obtaining the notebook_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (no search query) and suggests using list_notebooks to find the notebook_id. However, it does not explicitly state when not to use this tool versus alternatives like search_notes or other note tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states what the tool does (list tags) but does not disclose behavioral traits like whether it is read-only, any authorization requirements, or side effects. The agent must infer safety from context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with 10 words, no filler. It is perfectly concise and front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with an output schema, the description is complete: it states what is listed (tags with ids) and why it is useful (for use with 'get_notes_by_tag'). No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description does not need to add parameter semantics, and it appropriately clarifies the output context (tags with ids). Baseline 4 for 0 parameters is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('List all Joplin tags') and the resource ('tags with their ids'). It also specifies the intended usage context ('for use with get_notes_by_tag'), distinguishing it from sibling tools like 'get_notes_by_tag' itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: to retrieve tag ids for use with 'get_notes_by_tag'. It provides clear context but does not explicitly state when not to use it or mention alternatives, though the sibling list hints at other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool lists all notebooks with their ids, which is accurate and non-destructive. However, it does not disclose any behavioral traits such as pagination, ordering, or rate limits. For a zero-parameter tool, the description is minimal but adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that conveys the essential purpose and a hint of usage. No wasted words—every part contributes value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists) and the presence of sibling tools, the description is sufficient. It could optionally mention that notebooks are hierarchical, but the output schema likely covers return fields. Overall, it is complete enough for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage via description (the schema itself is empty). There is no need for additional parameter semantics. The baseline for no parameters is 4, and the description does not need to add more.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all Joplin notebooks with their ids, providing the specific verb 'list' and resource 'notebooks'. It also hints at a primary use case (for create_note). Among sibling tools, no other tool lists notebooks, so it is well-distinguished.
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 mentions a use case ('for use with create_note'), giving context on when to use it. However, it does not explicitly state when not to use it or compare to alternatives like search_notes or list_notes_in_notebook. The guidance is clear but could be more complete.
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:

[![joplin-mcp MCP server](https://glama.ai/mcp/servers/johnsarie27/joplin-mcp/badges/card.svg)](https://glama.ai/mcp/servers/johnsarie27/joplin-mcp)

Score Badge

Copy to your README.md:

[![joplin-mcp MCP server](https://glama.ai/mcp/servers/johnsarie27/joplin-mcp/badges/score.svg)](https://glama.ai/mcp/servers/johnsarie27/joplin-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/johnsarie27/joplin-mcp'

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