Skip to main content
Glama
dweigend

Joplin MCP Server

by dweigend

get_note

Retrieve a specific note by its ID from Joplin to access its content and data for reading or further processing.

Instructions

Get a specific note by ID.

Args:
    note_id: ID of the note to retrieve

Returns:
    Dictionary containing the note data

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
note_idYes

Implementation Reference

  • The main handler function for the 'get_note' MCP tool, decorated with @mcp.tool() which also serves as registration. It retrieves the note using JoplinAPI and returns a formatted dictionary response.
    @mcp.tool()
    async def get_note(note_id: str) -> Dict[str, Any]:
        """Get a specific note by ID.
        
        Args:
            note_id: ID of the note to retrieve
        
        Returns:
            Dictionary containing the note data
        """
        if not api:
            return {"error": "Joplin API client not initialized"}
        
        try:
            note = api.get_note(note_id)
            return {
                "status": "success",
                "note": {
                    "id": note.id,
                    "title": note.title,
                    "body": note.body,
                    "created_time": note.created_time.isoformat() if note.created_time else None,
                    "updated_time": note.updated_time.isoformat() if note.updated_time else None,
                    "is_todo": note.is_todo
                }
            }
        except Exception as e:
            logger.error(f"Error getting note: {e}")
            return {"error": str(e)}
  • Supporting helper function in JoplinAPI class that performs the actual API call to fetch the note by ID and parses the response into a JoplinNote object.
    def get_note(self, note_id: str) -> JoplinNote:
        """Get a specific note by ID.
    
        Args:
            note_id: ID of the note to retrieve
    
        Returns:
            JoplinNote object
    
        Raises:
            requests.exceptions.RequestException: If note not found or other error
        """
        # Explizit alle wichtigen Felder anfordern, insbesondere den Body
        params = {
            "fields": "id,title,body,created_time,updated_time,is_todo"
        }
        response = self._make_request("GET", f"notes/{note_id}", params=params)
        return JoplinNote.from_api_response(response)
  • Dataclass defining the structure and type annotations for Joplin note objects, used in the tool's output processing.
    class JoplinNote:
        """Represents a Joplin note with its attributes.
    
        Reference: https://joplinapp.org/help/api/references/rest_api/#notes
    
        Attributes:
            id: Unique identifier
            title: Note title
            body: Note content in Markdown format
            created_time: Creation timestamp
            updated_time: Last update timestamp
            is_conflict: Whether this note is in conflict
            latitude: Geographic latitude
            longitude: Geographic longitude
            altitude: Geographic altitude
            author: Note author
            source_url: Source URL
            is_todo: Whether this is a todo item
            todo_due: Todo due date
            todo_completed: Todo completion date
            source: Note source
            source_application: Source application
            application_data: Application-specific data
            order: Sort order
            user_created_time: User creation timestamp
            user_updated_time: User update timestamp
            encryption_cipher_text: Encrypted content
            encryption_applied: Whether encryption is applied
            markup_language: Markup language used
            is_shared: Whether note is shared
            share_id: Share identifier
            conflict_original_id: Original note ID if in conflict
            master_key_id: Master key identifier
            parent_id: Parent folder ID
        """
    
        id: str
        title: str
        body: str | None = None
        created_time: datetime | None = None
        updated_time: datetime | None = None
        is_conflict: bool = False
        latitude: float | None = None
        longitude: float | None = None
        altitude: float | None = None
        author: str | None = None
        source_url: str | None = None
        is_todo: bool = False
        todo_due: datetime | None = None
        todo_completed: datetime | None = None
        source: str | None = None
        source_application: str | None = None
        application_data: dict[str, Any] | None = None
        order: int | None = None
        user_created_time: datetime | None = None
        user_updated_time: datetime | None = None
        encryption_cipher_text: str | None = None
        encryption_applied: bool = False
        markup_language: int | None = None
        is_shared: bool = False
        share_id: str | None = None
        conflict_original_id: str | None = None
        master_key_id: str | None = None
        parent_id: str | None = None
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 of behavioral disclosure. It states the tool retrieves a note by ID but doesn't cover critical aspects like error handling (e.g., what happens if the note doesn't exist), authentication requirements, rate limits, or whether it's read-only (implied but not confirmed). This leaves significant gaps for safe and effective use.

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 and concise, using clear sections for 'Args' and 'Returns.' It avoids unnecessary details, though the 'Returns' section could be more specific (e.g., mentioning fields like title or content). Overall, it's efficient but not perfectly front-loaded, as the core purpose is stated upfront.

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 (single parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic operation and parameter but lacks details on behavior, error handling, and output structure. Without annotations or an output schema, users must infer return values from the vague 'Dictionary containing the note data,' which is insufficient for reliable use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds minimal semantics beyond the input schema. It explains that 'note_id' is the 'ID of the note to retrieve,' which clarifies the parameter's purpose but doesn't provide format details (e.g., UUID, numeric) or constraints. With 0% schema description coverage, this is a baseline score—it compensates slightly but not fully for the lack of schema documentation.

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: 'Get a specific note by ID.' It uses a specific verb ('Get') and resource ('note'), making it easy to understand. However, it doesn't explicitly differentiate from siblings like 'search_notes' (which likely retrieves multiple notes based on criteria), so it falls short of 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 siblings like 'search_notes' for retrieving multiple notes or 'create_note'/'update_note' for write operations. Without this context, users might struggle to choose the right tool in scenarios requiring note retrieval.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

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/dweigend/joplin-mcp-server'

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