Free, read-only access to Alicia's published English and Chinese notes on Houdini, Three.js, OpenUSD and AI-assisted 3D workflows. Search articles, read full Markdown, browse topics and recent notes. Results include canonical source URLs and author attribution. No account or API key; Streamable HTTP with four read-only tools. Digital Garden is the interactive 3D flower artwork at digitalgarden.si. Setup: https://digitalgarden.si/agents/?utm_source=glama&utm_medium=referral&utm_campaign=listing
Scored across 4 tools
Each tool maps to a distinct access pattern: full-text fetch by slug/URL (get_article), chronological browsing (list_recent_articles), taxonomy overview (list_topics), and keyword discovery (search_articles). Descriptions explicitly cross-reference each other with negative guidance ('do not use it to discover notes — use search_articles'), leaving almost no room for misselection.
All four follow a clean verb_noun snake_case pattern (get_article, list_recent_articles, list_topics, search_articles) with consistent list_* prefix for enumeration tools. Minor wrinkle: the domain is referred to as 'notes' in prose but 'articles' in every tool name, a small terminology mismatch that could momentarily confuse.
Four tools precisely cover the read-only surface of a single-author garden: discover by keyword, discover by recency, discover by topic, and retrieve full text. Nothing feels padded or missing at the operation level.
Together the tools form a complete read path from discovery to full text, with language handling and canonical URLs covered. Gaps exist only on the edges — no pagination/limit parameters for large result sets and no tool for enumerating topics' articles beyond list_topics' inline listing, but an agent can work around both.
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_articlesRead-only search and Markdown access to liz's public docs, prompts, resources, and an MCP App.
Personal context for every AI: search, read, and write back to your private Markdown library.
Cloud Blender for AI agents: build, inspect, render and animate 3D scenes over remote MCP. Keep editable .blend projects and export GLB or STL. Make your first 3D asset free—30 compute minutes per UTC month, no credit card. First 100 eligible Free account owners to use all 30 minutes in one UTC month by December 31, 2026 UTC receive one calendar month of beta free: 4 compute hours per UTC month, 2 concurrent workers per deployment, 2 deployments, 2048×2048 renders at up to 256 samples, and 10 GiB storage. Existing usage counts toward the 4-hour allowance. Limited to 100 rewards; expires January 1, 2027 00:00 UTC. Free resumes afterward without an automatic charge. Examples, eligibility and terms: https://sceneplane.online/launch?utm_source=glama&utm_medium=directory&utm_campaign=first100
Discover Drawcall workflows for 3D apps and asset creation; read APIs and approve CLI logins.
Add one secure layer between your agents and this server.
