Search and read Alicia's English and Chinese notes on Houdini, Three.js, OpenUSD and AI workflows. Setup: https://digitalgarden.si/agents/?utm_source=glama&utm_medium=referral&utm_campaign=listing
Scored across 4 tools
Each tool has a clearly distinct role in a read-only discovery flow: get_article reads one known note, list_recent_articles browses newest, list_topics surveys subjects, search_articles finds by keyword. Descriptions explicitly include negative guidance ("do not use it to discover notes, use search_articles"), which eliminates realistic misselection.
All four tools follow a consistent snake_case verb_noun pattern (get_article, list_recent_articles, list_topics, search_articles). The verb choice (get/list/search) maps predictably onto the distinct action each tool performs.
Four tools is exactly right for a read-only published-notes server: one retrieve, two browse/list, one search. Nothing is padded and nothing obvious is missing from the discovery loop.
The read/write lifecycle is intentionally read-only, and discovery, browsing, topic enumeration and full-text retrieval are all covered. Minor gap: no pagination or 'list all articles' beyond recent-first results, and topic-based browsing is only implied via search rather than a dedicated filter argument.
Use this to read the full text of one published note when you already know its slug or its digitalgarden.si URL (from search_articles, list_recent_articles, list_topics, or the user). Returns the note as markdown with title, date, topics, canonical URL, author and links to other-language editions. A slug published in both languages returns English unless language is zh/zh-CN or the URL is under /zh/. Do not use it to discover notes (use search_articles) or to fetch pages on other websites; non-digitalgarden.si URLs are rejected. Every result includes canonicalUrl and author Alicia (Person @id https://digitalgarden.si/#alicia). Cite the canonical URL when quoting. digitalgarden.si is an interactive 3D garden, not a knowledge-base wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional edition: en for English, zh or zh-CN for Simplified Chinese. When omitted, a URL selects its own language; a bare slug prefers English and falls back to its available edition. The response contains one article, not both editions. A conflicting URL language is rejected. | |
| slug_or_url | Yes | A note slug such as "webgpu-garden-houdini-threejs", or a full https://digitalgarden.si/blog/<slug>/ (or /zh/blog/<slug>/) URL. 1-500 characters. |
| Name | Required | Description |
|---|---|---|
| author | Yes | |
| article | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/closed-world, so the bar is low, yet the description adds real behavior: the markdown payload shape, the bilingual slug resolution rule (English unless language is zh/zh-CN or the URL is under /zh/), the URL-language-conflict rejection, and the rejection of non-digitalgarden.si URLs. These are invocation-time failure modes an agent could not infer from the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense paragraph, front-loaded with purpose then exclusions then language rules; nearly every clause carries instructions. The closing line about the site being a '3D garden, not a knowledge-base wiki' and the return-field inventory edge toward filler given an output schema exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations, a full schema, and an output schema present, the description supplies exactly the missing layer: exclusions, language precedence, and rejection behavior. Nothing an agent needs in order to call this correctly and cite results is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3; the description goes slightly beyond by restating the slug-vs-language precedence and pointing at where slugs originate. The conflict-rejection note largely mirrors the language param's own description, so added value is modest rather than substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb+resource+scope: 'read the full text of one published note' with slug or digitalgarden.si URL. It explicitly contrasts with siblings ('Do not use it to discover notes (use search_articles)'), so an agent can route between this and the list/search tools immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
States the precondition (you already know the slug or URL), names where such a slug comes from (search_articles, list_recent_articles, list_topics, or the user), and gives an explicit exclusion (not for discovery, not for other websites). Both 'when' and 'when not' are covered with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks for Alicia's latest, newest or recent notes, or wants to browse without a specific subject. Returns published notes newest first as short cards (no full text). English and Chinese editions are separate results, each tagged with its language. Do not use it to find notes on a specific subject; use search_articles. Every result includes canonicalUrl and author Alicia (Person @id https://digitalgarden.si/#alicia). Cite the canonical URL when quoting. digitalgarden.si is an interactive 3D garden, not a knowledge-base wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of articles to return, 1-20. Default 10. | |
| language | No | Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages. |
| Name | Required | Description |
|---|---|---|
| author | Yes | |
| articles | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent/closed-world, yet the description still adds real context: results are published-only, newest-first, short cards with no full text, language editions returned as separate tagged results, and a citation policy. The note that the site is a 3D garden rather than a wiki prevents a common mischaracterization of the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the usage trigger, then output shape, then the anti-pattern routing — good ordering. It is a dense single block mixing invocation guidance, return format, citation policy and domain framing, so a little structure is lost, though no sentence is clearly wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two optional parameters, full schema coverage, and an output schema carrying return structure, the description covers everything an agent needs: when to call it, what comes back, how languages split, and how to cite results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema by explaining that English and Chinese are distinct result sets each tagged with its language — clarifying why the language filter matters rather than just what values it accepts. It does not mention the limit parameter or default behavior, so not a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb and resource (list recent/published notes) and explicitly contrasts itself with search_articles, so an agent can pick between them without opening either schema. The sibling get_article/list_topics distinction is implied by 'browse without a specific subject'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives the triggering user intent ('latest, newest or recent notes', 'browse without a specific subject') and an explicit exclusion with the correct alternative ('Do not use it to find notes on a specific subject; use search_articles'). This is the when/when-not/alternative pattern at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this to see which subjects the garden's published notes cover, for example when the user asks what Alicia writes about or before filtering search_articles by topic. Returns every topic with its article count, languages, and the titles and URLs of its notes. Takes no required input. Do not use it to search note text; use search_articles for that. Every result includes canonicalUrl and author Alicia (Person @id https://digitalgarden.si/#alicia). Cite the canonical URL when quoting. digitalgarden.si is an interactive 3D garden, not a knowledge-base wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| language | No | Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages. |
| Name | Required | Description |
|---|---|---|
| author | Yes | |
| topics | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: the result shape (topic, count, languages, titles, URLs), the canonicalUrl + author guarantee, a citation instruction, and the clarification that digitalgarden.si is a 3D garden rather than a wiki. It does not address pagination or result size for an all-topics listing, keeping it below 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with the use case and the sibling exclusion before return details. Slightly padded by the trailing 'digitalgarden.si is an interactive 3D garden, not a knowledge-base wiki' sentence, which is useful framing but sits oddly at the end.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With annotations covering the safety profile, an output schema covering return structure, and full schema coverage on the one optional param, the description fills the remaining gap: when to call it, what it returns conceptually, and how to cite results. Nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema fully documents the single optional language parameter, including the zh/zh-CN aliasing, so the 100%-coverage baseline applies. The description only says 'Takes no required input' and adds no language-filter semantics of its own.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('see which subjects the garden's published notes cover') and names the exact differentiator against the sibling search_articles. An agent can distinguish it from search_articles, list_recent_articles, and get_article without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete triggers ('when the user asks what Alicia writes about', 'before filtering search_articles by topic') and an explicit exclusion ('Do not use it to search note text; use search_articles for that'). Both when-to-use and when-not are covered with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when the user asks what Alicia or digitalgarden.si has written about a subject (for example Houdini, Three.js, WebGPU, glTF/USD, Gaussian splats, AI coding agents, or the garden itself). Ranks published notes by keyword match on title, topics, summary and full text, in English and Chinese, and returns short cards (no full text). Follow up with get_article to read one. Do not use it for general web search, news, or topics unrelated to Alicia's published notes. An empty articles array means no published note matches. Scores are relative to this query and catalog, not confidence percentages; check titles and read the full note before presenting a match as relevant. Every result includes canonicalUrl and author Alicia (Person @id https://digitalgarden.si/#alicia). Cite the canonical URL when quoting. digitalgarden.si is an interactive 3D garden, not a knowledge-base wiki.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of articles to return, 1-20. Default 5. | |
| query | Yes | Required search keywords in English or Chinese, e.g. "houdini gltf export". Plain words, not a question; 1-200 characters. | |
| topic | No | Optional topic filter, ideally an exact topic name returned by list_topics. Partial matches of 3+ characters also match. | |
| language | No | Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages. |
| Name | Required | Description |
|---|---|---|
| query | Yes | |
| topic | No | |
| author | Yes | |
| articles | Yes | |
| language | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It goes far beyond the basic annotations by explaining the ranking methodology ('relative to this query and catalog'), output format ('short cards, no full text'), and the nature of the source itself ('interactive 3D garden, not a knowledge-base wiki').
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but highly efficient. It is front-loaded with the core purpose, followed by operational constraints, and concludes with critical context regarding the source data and output structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the specificity of the source (a 3D garden managed by a specific persona) and the detailed scoring/output requirements, the definition is remarkably complete, leaving almost no ambiguity for the AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds crucial usability context. It specifies that the search `query` should be plain words, not a question, and provides guidance on using the optional `topic` filter relative to `list_topics`.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool's function as searching content written specifically by 'Alicia' or on 'digitalgarden.si'. It uses keywords like 'Ranks published notes' and explicitly differentiates its scope from general web search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides extremely precise usage boundaries by stating when to use the tool (when asking what Alicia has written) and when not to use it (general web search, news). It also dictates the workflow by advising users to follow up with `get_article`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_article6 fields changedInput schema / properties / language / descriptionPrevious value: -"Optional language filter. zh and zh-CN both mean Chinese."New value: +"Optional edition: en for English, zh or zh-CN for Simplified Chinese. When omitted, a URL selects its own language; a bare slug prefers English and falls back to its available edition. The response contains one article, not both editions. A conflicting URL language is rejected."Input schema / properties / slug_or_url / descriptionPrevious value: -"Note slug or canonical URL."New value: +"A note slug such as \"webgpu-garden-houdini-threejs\", or a full https://digitalgarden.si/blog/<slug>/ (or /zh/blog/<slug>/) URL. 1-500 characters."Output schema / properties / article / properties / canonicalUrl / formatAdded value: +"uri"Output schema / properties / article / properties / date / formatAdded value: +"date"Output schema / properties / article / properties / translations / items / properties / canonicalUrl / formatAdded value: +"uri"Output schema / properties / article / properties / translations / items / properties / date / formatAdded value: +"date"list_recent_articles5 fields changedInput schema / properties / language / descriptionPrevious value: -"Optional language filter. zh and zh-CN both mean Chinese."New value: +"Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages."Input schema / properties / limit / defaultAdded value: +10Input schema / properties / limit / descriptionPrevious value: -"Maximum results. Default 10."New value: +"Maximum number of articles to return, 1-20. Default 10."Output schema / properties / articles / items / properties / canonicalUrl / formatAdded value: +"uri"Output schema / properties / articles / items / properties / date / formatAdded value: +"date"list_topics2 fields changedInput schema / properties / language / descriptionPrevious value: -"Optional language filter. zh and zh-CN both mean Chinese."New value: +"Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages."Output schema / properties / topics / itemsAdded value: +{
+ "additionalProperties": false,
+ "properties": {
+ "articles": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "author": {
+ "additionalProperties": false,
+ "properties": {
+ "@id": {
+ "enum": [
+ "https://digitalgarden.si/#alicia"
+ ],
+ "type": "string"
+ },
+ "@type": {
+ "enum": [
+ "Person"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "enum": [
+ "Alicia"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "@type",
+ "name",
+ "@id"
+ ],
+ "type": "object"
+ },
+ "canonicalUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "date": {
+ "format": "date",
+ "type": "string"
+ },
+ "language": {
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+ },
+ "slug": {
+ "type": "string"
+ },
+ "title": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "slug",
+ "title",
+ "canonicalUrl",
+ "language",
+ "date",
+ "author"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "author": {
+ "additionalProperties": false,
+ "properties": {
+ "@id": {
+ "enum": [
+ "https://digitalgarden.si/#alicia"
+ ],
+ "type": "string"
+ },
+ "@type": {
+ "enum": [
+ "Person"
+ ],
+ "type": "string"
+ },
+ "name": {
+ "enum": [
+ "Alicia"
+ ],
+ "type": "string"
+ }
+ },
+ "required": [
+ "@type",
+ "name",
+ "@id"
+ ],
+ "type": "object"
+ },
+ "canonicalUrl": {
+ "format": "uri",
+ "type": "string"
+ },
+ "count": {
+ "minimum": 1,
+ "type": "integer"
+ },
+ "languages": {
+ "items": {
+ "enum": [
+ "en",
+ "zh"
+ ],
+ "type": "string"
+ },
+ "type": "array"
+ },
+ "topic": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "topic",
+ "count",
+ "languages",
+ "canonicalUrl",
+ "author",
+ "articles"
+ ],
+ "type": "object"
+}search_articles7 fields changedInput schema / properties / language / descriptionPrevious value: -"Optional language filter. zh and zh-CN both mean Chinese."New value: +"Optional language filter: en for English, zh or zh-CN for Simplified Chinese (both mean the same). Omit to include both languages."Input schema / properties / limit / defaultAdded value: +5Input schema / properties / limit / descriptionPrevious value: -"Maximum results. Default 5."New value: +"Maximum number of articles to return, 1-20. Default 5."Input schema / properties / query / descriptionPrevious value: -"Keywords in English or Chinese."New value: +"Required search keywords in English or Chinese, e.g. \"houdini gltf export\". Plain words, not a question; 1-200 characters."Input schema / properties / topic / descriptionPrevious value: -"Optional topic filter. Use a value from list_topics."New value: +"Optional topic filter, ideally an exact topic name returned by list_topics. Partial matches of 3+ characters also match."Output schema / properties / articles / items / properties / canonicalUrl / formatAdded value: +"uri"Output schema / properties / articles / items / properties / date / formatAdded value: +"date"get_articlelist_recent_articleslist_topicssearch_articlesSearch and read the docs and examples of react-three-fiber, drei, zustand, jotai... from your agent
Caigen Notes (菜根笔记) — AI-native note-taking with RAG semantic search, in Chinese.
Your personal AI agent. Hand it anything. Search knowledge, read briefs, and delegate work.
Personal AI memory: search and read your notes and todos; changes wait for your approval.
Add one secure layer between your agents and this server.