Bear Notes MCP Server

by netologist

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: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap between find_notes_by_title and search_bear_notes, as both search for notes based on text criteria. However, the descriptions clarify that find_notes_by_title focuses on title matching while search_bear_notes searches both title and content, reducing confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern with snake_case, such as find_code_examples, get_bear_note, and list_bear_tags. This uniformity makes the tool set predictable and easy to understand.
Tool Count5/5
With 7 tools, the server is well-scoped for managing Bear notes, covering key operations like searching, retrieving, and listing without being overwhelming. Each tool serves a clear purpose, making the count appropriate for the domain.
Completeness4/5
The tool set provides strong coverage for reading and searching notes, including specific use cases like code and Kubernetes examples. However, it lacks write operations (e.g., create, update, or delete notes), which could limit full lifecycle management, though this may be intentional for the server's design.
Average 3/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool finds notes by title and describes parameters, but lacks critical behavioral details such as whether this is a read-only operation, how results are returned (e.g., pagination, format), error handling, or any rate limits. The description is minimal and doesn't adequately cover behavioral traits beyond basic functionality.
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 appropriately sized and structured with a clear purpose statement followed by Args and Returns sections. Every sentence adds value, with no redundant information. However, the 'Returns' section is somewhat vague ('Notes matching the title criteria'), which slightly reduces efficiency.
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 complexity (2 parameters, no annotations, no output schema), the description is incomplete. It covers basic purpose and parameters but lacks details on behavioral traits, output format, error handling, and differentiation from sibling tools. For a search tool with no structured support, this leaves significant gaps for an AI agent to use it correctly.
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 description adds meaningful context for both parameters: 'title_query' is explained as 'Title text to search for' and 'exact_match' as 'Whether to match title exactly or use partial matching'. With 0% schema description coverage, this compensates well by clarifying the purpose and behavior of each parameter, though it doesn't specify syntax or examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Find notes by title' which clearly indicates the verb (find) and resource (notes), but it's vague about scope and doesn't differentiate from sibling tools like 'search_bear_notes' or 'get_recent_notes'. It specifies the search criteria (title) but lacks detail about what 'notes' refers to in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'search_bear_notes' or 'get_recent_notes'. The description only states what the tool does without indicating context, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool does but lacks important behavioral details: no information about permissions needed, rate limits, whether it searches all notes or specific ones, how results are sorted, or what happens when parameters are omitted. The return description is minimal.
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 appropriately concise with clear sections (purpose, args, returns). Each sentence serves a purpose, though the 'Args' and 'Returns' sections could be integrated more smoothly. No wasted words, but could be slightly more polished in structure.
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 3-parameter search tool with no annotations and no output schema, the description provides basic purpose and parameter information but lacks important context. It doesn't explain the search scope, result format, error conditions, or how it differs from sibling tools. The return description is minimal ('Notes containing code examples with extracted code blocks').
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 compensate. It provides basic semantic meaning for all three parameters (language, topic, limit) with examples for language and topic, which adds value beyond the bare schema. However, it doesn't explain parameter interactions, validation rules, or what happens with empty/default values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find code examples in Bear notes' with specific parameters for language, topic, and limit. It distinguishes from siblings like 'find_notes_by_title' or 'search_bear_notes' by focusing on code examples, but doesn't explicitly differentiate from 'find_kubernetes_examples' which appears to be a specialized version.
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 like 'find_kubernetes_examples' (which seems related), 'search_bear_notes', or 'get_recent_notes'. It mentions parameters but gives no context about when this tool is appropriate versus other search methods.
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 full burden. It states it 'finds' examples (implies read-only) and returns notes, but lacks behavioral details: search scope (all notes/tagged notes?), match criteria (exact/partial?), return format (note titles/content?), or limitations (pagination/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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with purpose, args, and returns sections in 4 sentences. The purpose sentence is front-loaded, but the 'Args:' and 'Returns:' labels add minor verbosity without enhancing clarity for an AI agent.
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?
Incomplete for a search tool with no annotations or output schema. The description lacks details on search behavior (e.g., fuzzy matching), result format (e.g., note IDs vs content), and constraints (e.g., max results). Given 1 parameter with 0% schema coverage, it should explain parameter usage more thoroughly.
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 compensate. It adds meaning by explaining 'resource_type' as 'Kubernetes resource type to search for (deployment, service, configmap, etc.)', providing examples beyond the schema's generic 'Resource Type' title. However, it doesn't clarify if 'etc.' includes custom resources or if the search is case-sensitive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Find Kubernetes manifest examples in Bear notes' (verb+resource+scope). It distinguishes from siblings like 'find_code_examples' by specifying Kubernetes manifests, but doesn't explicitly differentiate from 'search_bear_notes' which might also find notes with Kubernetes content.
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 vs alternatives. It doesn't mention when to prefer 'find_code_examples' (for general code) or 'search_bear_notes' (for broader searches), nor does it specify prerequisites like needing Bear notes with Kubernetes examples.
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?
With no annotations provided, the description carries full burden for behavioral disclosure. It states the tool retrieves notes but doesn't describe what 'recently modified' means operationally (e.g., modification timestamp vs creation), whether results are sorted, pagination behavior, error conditions, or authentication needs. For a read operation with zero annotation coverage, this leaves significant gaps.
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 appropriately sized and front-loaded with the core purpose in the first line. The Args/Returns sections add necessary structure without redundancy. However, the 'Returns' section ('Recently modified notes') is somewhat tautological with the first line and could be more informative.
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 2 parameters with 0% schema coverage and no output schema, the description provides basic parameter semantics but lacks behavioral context (sorting, errors, etc.). For a simple read tool, it's minimally adequate but has clear gaps. The absence of annotations increases the burden that the description doesn't fully meet.
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 compensate. It adds basic meaning for both parameters ('days: Number of days to look back', 'limit: Maximum number of results'), which goes beyond the schema's bare titles. However, it doesn't provide format details, constraints, or examples (e.g., valid ranges for days/limit). The description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with 'Get recently modified notes' - a specific verb ('Get') and resource ('notes') with a temporal qualifier ('recently modified'). It distinguishes from siblings like 'find_notes_by_title' or 'search_bear_notes' by focusing on recency rather than content-based search. However, it doesn't explicitly contrast with all siblings (e.g., 'get_bear_note' might fetch a single note).
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. It doesn't mention when to prefer this over 'search_bear_notes' or 'find_notes_by_title', nor does it specify prerequisites or exclusions. The context is implied through the name and description but not explicitly stated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('List all tags') and return type ('Sorted list'), but lacks details on permissions, rate limits, or any side effects. This is a significant gap 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main action and includes a brief return statement, making it efficient. However, the structure could be slightly improved by integrating the return information more seamlessly, and it lacks any extra context that might be useful.
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's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return, but for a tool with no annotations, it should ideally include more behavioral context, such as how tags are sourced or any limitations.
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 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate, but it could have mentioned optional behaviors like sorting criteria. Baseline is 4 for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('List') and resource ('all tags from Bear App notes'), making the purpose unambiguous. However, it does not explicitly differentiate from sibling tools like 'search_bear_notes' or 'find_notes_by_title', which might also involve tags, so it lacks sibling distinction for a perfect score.
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. It does not mention scenarios like retrieving all tags versus searching for specific tags or notes, nor does it reference sibling tools, leaving usage context unclear.
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?
With no annotations provided, the description carries full burden but offers minimal behavioral insight. It mentions searching 'in title and content' and returning 'List of matching notes with metadata', but doesn't disclose critical traits like whether this is a read-only operation, how results are sorted, if there's pagination, or what 'metadata' includes. For a search tool with 3 parameters, this leaves significant gaps.
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 a clear header and bullet-point-like sections for Args and Returns. It's front-loaded with the core purpose. However, the 'Args' and 'Returns' labels add minor redundancy, and it could be more concise by integrating parameter details into a single sentence.
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 3 parameters with 0% schema coverage and no output schema, the description does an adequate job explaining inputs and the return type. However, it lacks details on output structure (what metadata?), error conditions, or performance limits. For a search tool with siblings, more context on differentiation would improve completeness.
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 description coverage is 0%, so the description must compensate—and it does by explaining all 3 parameters: 'query' searches title/content, 'tag' filters without # symbol, and 'limit' sets max results. This adds meaningful context beyond the bare schema, though it doesn't detail query syntax (e.g., wildcards) or tag behavior (e.g., multiple tags).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Search') and resource ('Bear App notes'), making the purpose immediately understandable. It distinguishes this tool from siblings like 'find_notes_by_title' or 'get_recent_notes' by specifying it searches both title and content. However, it doesn't explicitly contrast with 'find_code_examples' or 'find_kubernetes_examples', which might be more specialized search tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'find_notes_by_title' (which might search only titles) or 'list_bear_tags' (which might help with tag discovery). There's no context about prerequisites, such as whether Bear App needs to be running or authenticated.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool retrieves a note by ID and returns content with metadata, but lacks details on error handling (e.g., what happens if the ID is invalid), permissions, or rate limits. This is a significant gap for a retrieval 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise and well-structured, using clear sections for 'Args' and 'Returns' in just three sentences. Every sentence adds value without redundancy, making it easy to parse and front-loaded with the core purpose.
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's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic operation and parameter meaning but lacks details on behavioral aspects like errors or output structure, leaving gaps that could hinder effective use by an agent.
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 description adds meaningful context for the single parameter 'note_id' by specifying it as 'Bear note's unique identifier,' which clarifies its purpose beyond the schema's basic title. With 0% schema description coverage and only one parameter, this compensates well, though it doesn't detail format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb ('Get') and resource ('Bear note by ID'), making it immediately understandable. However, it doesn't differentiate from sibling tools like 'get_recent_notes' or 'search_bear_notes' beyond the ID-based retrieval, which prevents a perfect score.
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. It doesn't mention when to prefer this over sibling tools like 'get_recent_notes' or 'search_bear_notes', nor does it specify prerequisites such as needing a valid note ID, leaving usage context unclear.
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:

[![mcp-bear-notes MCP server](https://glama.ai/mcp/servers/netologist/mcp-bear-notes/badges/card.svg)](https://glama.ai/mcp/servers/netologist/mcp-bear-notes)

Score Badge

Copy to your README.md:

[![mcp-bear-notes MCP server](https://glama.ai/mcp/servers/netologist/mcp-bear-notes/badges/score.svg)](https://glama.ai/mcp/servers/netologist/mcp-bear-notes)

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/netologist/mcp-bear-notes'

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