Skip to main content
Glama

add_note

Create a new flashcard in Anki by specifying the deck, note type, field content, tags, and optional images. Supports code formatting with tags and MathJax equations with tags.

Instructions

Add a flashcard to Anki. Ensure you have looked at examples before you do this, and that you have got approval from the user to add the flashcard.

For code examples, use <code> tags to format your code.
e.g. <code>def fibonacci(n):
if n <= 1:
    return n
return fibonacci(n-1) + fibonacci(n-2)</code>

For MathJax, use the <math> tag to format your math equations. This will automatically render the math equations in Anki.
# e.g. <math>\frac{d}{dx}[3\sin(5x)] = 15\cos(5x)</math>

To attach images to a card, use the picture parameter. Each picture object must have a filename
and exactly one source (url, data, or path). The fields list specifies which card fields get the <img> tag inserted.

## How to attach images based on the source:

**User provides a URL:**
[{"url": "https://example.com/photo.jpg", "filename": "photo.jpg", "fields": ["Back"]}]

**User provides a local file (e.g. screenshot, downloaded image):**
[{"path": "/absolute/path/to/image.png", "filename": "image.png", "fields": ["Back"]}]

**Base64-encoded data (for small images only):**
[{"data": "iVBORw0KGgo...", "filename": "diagram.png", "fields": ["Back"]}]

IMPORTANT: When a user shares an image file or screenshot, prefer using "path" with the absolute
file path rather than trying to base64-encode the image contents. AnkiConnect reads the file directly
from disk which is faster and more reliable.

Args:
    deckName: str - The target deck name.
    modelName: str - The note type (model) name.
    fields: dict - Dictionary of field names and their string content.
    tags: List[str] - Optional list of tags.
    picture: List[dict] - Optional list of picture attachments. Each dict should have:
        - filename (str): Name for the stored image file.
        - url (str, optional): URL to download the image from.
        - path (str, optional): Absolute file path to a local image. Preferred for user-shared files.
        - data (str, optional): Base64-encoded image data.
        - fields (List[str]): Card field names where the <img> tag will be inserted.
        - skipHash (str, optional): MD5 hash to skip if file matches.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
deckNameYes
modelNameYes
fieldsYes
tagsNo
pictureNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must disclose behavioral traits. It explains image attachment methods and mentions that using file paths is faster and more reliable, but it lacks details on error handling, permissions, or the tool's side effects. The behavioral info is partial.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is verbose, repeating image insertion instructions and including long code/MathJax examples that could be condensed. Though front-loaded with the main action, it lacks conciseness and contains redundant explanations.

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 tool's complexity (5 params, nested objects), the description misses key context: no mention of the output schema (presumably a note ID), no prerequisites like Anki being open, and no error behavior. While it covers image handling well, overall completeness is lacking.

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 compensates well. It provides a detailed 'Args' section and extensive documentation for the 'picture' parameter with examples. However, 'fields' is only described as a dictionary of strings, adding minimal value over the schema.

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 starts with 'Add a flashcard to Anki', clearly stating the verb and resource. It is specific about creating a flashcard but does not explicitly differentiate from sibling tools like store_media_file, though the 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?

The description advises to look at examples and get user approval before adding, providing some usage context. However, it does not specify when not to use this tool or mention alternatives, leaving the usage implicit.

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/samefarrar/mcp-ankiconnect'

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