da-mcp demonstrates solid definition quality with consistent tool naming, clear descriptions, and well-structured Zod schemas. All 17 tools follow verb_noun naming conventions and provide meaningful descriptions. Tool annotations (readOnlyHint, idempotentHint) are present for most tools. However, several tools lack output schema documentation, and parameter descriptions could be more prescriptive about constraints and formats. Error handling guidance is minimal, most tools lack recovery hints for common failure scenarios.
Copy content from one location to another within a site. Creates a duplicate of the source at the destination.
Create a new source file in a site with the specified content.
Create a snapshot version of a source file in a site. Versions are also created automatically when a file is updated, so this is mainly useful to explicitly checkpoint a file before making risky changes.
Delete a source file from a site. Use with caution as this operation cannot be undone.
Get the content of a specific source file from a site. Returns the file content and metadata.
Get the content of a specific version of a source file. The versionId must be the "url" value for that version from a prior da_get_versions call — it is an opaque identifier (its exact shape differs by backend) and should not be constructed manually.
Output schemas are not documented. Tools like da_list_sources, da_get_source, da_get_versions, and da_lookup_* have no visible return type specifications in the source code. LLMs cannot plan downstream tool calls or extract required fields without knowing what structure to expect.
Error handling guidance is absent. Tools do not document what errors they may throw, how to recover from them, or what the LLM should do next. For destructive operations (da_delete_source, da_publish_content), there is no pre-flight confirmation or dry-run pattern.
Parameter descriptions lack prescriptive constraints. For example, 'path' parameters say 'Path to the file' but do not specify format restrictions (leading slashes, file extension handling, max length). The server-level INSTRUCTIONS explain path normalization, but tool descriptions should repeat this for clarity.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | B | 78 | 2026-07-28+ | v2 |
| 2026-03-09 | B | 70 | 1.26.0+ | v1 |
Get version history for a source file in a site. Returns a list of versions with timestamps and metadata.
List all sources and directories in a site at a given path. Returns a list of files and folders with their metadata.
Lookup fragment references in a site. Returns information about content fragments.
Lookup media references in a site. Returns information about media assets including URLs and metadata.
Move content from one location to another within a site. The source file will be removed.
Preview a source file on the preview (staging) environment. Makes the content visible on the preview domain before publishing to live.
Publish a source file to the live (production) environment. Makes the content visible on the live domain to end users.
Remove a source file from the preview (staging) environment. The file will no longer be visible on the preview domain.
Unpublish a source file from the live (production) environment. The file will no longer be visible on the live domain to end users.
Update an existing source file in a site with new content.
Upload an image or media file to a site using base64-encoded data. When uploading images referenced in a page (e.g. during page creation or update), place the image in a child folder named after the page, sibling to the page file (e.g. page at "docs/my-page.html" → image at "docs/.my-page/image.png" with the folder name with a leading dot). For standalone media uploads unrelated to a specific page, use the "media" folder (e.g. "media/image.png").
da_lookup_media and da_lookup_fragment have generic, incomplete descriptions ('Lookup media references' / 'Lookup fragment references'). They should clarify what 'lookup' means, are they searching for usage, retrieving metadata, or validating existence? Current descriptions (70 chars each) are below the 194-char baseline.
No pagination or result-limiting guidance for discovery tools. da_list_sources could return hundreds of items; the description does not mention pagination, limit parameters, or a cap on results returned.
Tool composition issue: no batch variants. Agents that need to upload multiple media files must call da_upload_media N times. A batch_upload_media accepting an array of files would reduce round-trips and token overhead.