Skip to main content
Glama

create_note

Create notes in LunaTask with optional metadata for duplicate detection. Specify notebook, content, date, and source identifiers to organize information.

Instructions

Create a note in LunaTask. Accepts notebook_id, optional name/content, an ISO date_on, and optional source/source_id metadata for duplicate detection. Returns note_id or duplicate status.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
notebook_idNo
nameNo
contentNo
date_onNo
sourceNo
source_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Implementation Reference

  • The 'create_note_tool' method within the 'NotesTools' class handles the logic for creating a note. It parses the date, constructs a 'NoteCreate' payload, calls the API client, and returns a structured response indicating success, failure, or duplicate detection.
    async def create_note_tool(  # noqa: PLR0913
        self,
        ctx: ServerContext,
        notebook_id: str | None = None,
        name: str | None = None,
        content: str | None = None,
        date_on: str | None = None,
        source: str | None = None,
        source_id: str | None = None,
    ) -> dict[str, Any]:
        """Create a note in LunaTask with optional duplicate detection."""
    
        await ctx.info("Creating new note")
    
        parsed_date: date_class | None = None
        if date_on is not None:
            try:
                parsed_date = date_class.fromisoformat(date_on)
            except ValueError as error:
                message = f"Invalid date_on format. Expected YYYY-MM-DD format: {error!s}"
                await ctx.error(message)
                logger.warning("Invalid date_on provided for create_note: %s", date_on)
                return {
                    "success": False,
                    "error": "validation_error",
                    "message": message,
                }
    
        note_payload = NoteCreate(
            notebook_id=notebook_id,
            name=name,
            content=content,
            date_on=parsed_date,
            source=source,
            source_id=source_id,
        )
    
        try:
            async with self.lunatask_client as client:
                note_response = await client.create_note(note_payload)
        except Exception as error:
            return await self._handle_lunatask_api_errors(ctx, error, "note creation")
    
        if note_response is None:
            duplicate_message = (
                "Note already exists for this source/source_id in the provided notebook"
            )
            await ctx.info("Note already exists; duplicate create skipped")
            logger.info("Duplicate note detected for notebook=%s", notebook_id)
            return {
                "success": True,
                "duplicate": True,
                "message": duplicate_message,
            }
    
        await ctx.info(f"Successfully created note {note_response.id}")
        logger.info("Successfully created note %s", note_response.id)
        return {
            "success": True,
            "note_id": note_response.id,
            "message": "Note created successfully",
        }
  • The 'create_note' MCP tool is registered in the '_register_tools' method of the 'NotesTools' class using the mcp.tool decorator.
    async def _create_note(  # noqa: PLR0913
        ctx: ServerContext,
        notebook_id: str | None = None,
        name: str | None = None,
        content: str | None = None,
        date_on: str | None = None,
        source: str | None = None,
        source_id: str | None = None,
    ) -> dict[str, Any]:
        return await self.create_note_tool(
            ctx,
            notebook_id,
            name,
            content,
            date_on,
            source,
            source_id,
        )
    
    self.mcp.tool(
        name="create_note",
        description=(
            "Create a note in LunaTask. Accepts notebook_id, optional name/content, "
            "an ISO date_on, and optional source/source_id metadata for duplicate "
            "detection. Returns note_id or duplicate status."
        ),
    )(_create_note)
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 that the tool creates a note (mutation operation) and mentions duplicate detection behavior, which is valuable context. However, it doesn't cover important behavioral aspects like authentication requirements, error conditions, rate limits, or whether the operation is idempotent.

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 efficiently structured in two sentences that pack substantial information. The first sentence explains the core function and parameters, while the second covers the return behavior. Every word serves a purpose with zero wasted 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?

For a creation tool with no annotations but with an output schema, the description covers the essential creation operation, all parameter purposes, and mentions the return behavior (note_id or duplicate status). The main gap is lack of guidance about when to use this versus sibling creation tools, but otherwise it's reasonably 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?

With 0% schema description coverage, the description must compensate. It successfully explains the purpose of all 6 parameters: notebook_id (required context), name/content (optional content), date_on (ISO date format), and source/source_id (metadata for duplicate detection). This adds significant 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 the specific action ('Create a note in LunaTask') and resource ('note'), distinguishing it from sibling tools like create_journal_entry or create_task. It provides concrete details about the creation operation rather than just restating the tool name.

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 about when to use this tool versus alternatives like create_journal_entry or create_task. The description mentions duplicate detection but doesn't explain when this tool is preferred over other creation tools or what prerequisites might be needed.

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/tensorfreitas/lunatask-mcp'

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