Loading ToolBench
MCP (Model Context Protocol) endpoint served directly from a Grav site over Streamable HTTP
Strong foundation with 16 well-named tools, comprehensive schemas, and detailed descriptions. All tools have clear verb-noun naming (list_, get_, manage_, search_, upload_, delete_). Descriptions average ~180 chars and include permission requirements. Input schemas are complete with proper types and enums. However, output schemas are not documented, LLMs cannot predict response structure for chaining. Error handling guidance is minimal. Tool descriptions could better explain WHEN to use each tool vs alternatives (e.g., manage_blueprint_file vs upload_media distinction). Some parameter descriptions lack format/constraint details (e.g., 'filename' in upload_media has no length/character restrictions stated).
Delete a media file. Give "route" plus "filename" to delete a page's media; leave "route" out and give "path" to delete from the site media library. [Requires: api.media.write]
Get the full field schema (blueprint) for a page template, plugin config, theme config, user accounts, user groups (the edit form as "group", the create form as "group_new"), or system config. [Requires: api.pages.read for "page", api.config.read for "plugin"/"theme"/"config", api.access for "user", api.users.read for "group"/"group_new"]
Read configuration values for a specific scope. Scopes: "system", "site", "plugins/{name}" (e.g. "plugins/email"), "themes/{name}". Returns the config object and an ETag for use with update_config. [Requires: api.config.read]
Inspect installed packages: list the installed plugins or themes, read one package's details, or check what updates are available. [Requires: api.gpm.read]
Get all registered permission actions and their hierarchy. Useful for understanding what access levels exist and configuring user permissions. [Requires: api.users.read]
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination) for downstream tool chaining. E.g., list_media returns what fields? Does it include file URLs, dimensions, metadata? Without this, agents cannot extract IDs for delete_media or construct follow-up calls.
Error handling lacks recovery guidance. Descriptions state permission requirements but do not explain what to do if permission denied, resource not found, or operation fails. E.g., manage_packages 'update' action has no guidance on partial failures or retry strategy.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | <=2025-11-25 | v2 |
Get all taxonomy types and their current values used across the site. Taxonomy types (like "category", "tag") are defined in site config; values come from pages. [Requires: api.pages.read]
List the enumerable configuration scopes: core scopes (system, site, security, ...) plus any custom configs, filtered to what your permissions allow. Plugin and theme configs are NOT listed here, but ARE readable and writable directly — use get_config/update_config with scope "plugins/{name}" or "themes/{name}". [Requires: api.config.read]
List media files. Give "route" to list the media attached to that page (filename, type, size, dimensions, thumbnail URLs); leave "route" out to browse the site media library instead, where "path" picks a subfolder and search/type/page/per_page filter the listing. One or the other — passing both is an error. [Requires: api.media.read]
List all available page templates/blueprints. Each template defines a page type with its own set of fields. Use this before creating pages to know which templates are available. [Requires: api.pages.read]
Upload or delete a file referenced by a blueprint file/upload field (theme/plugin config form, account avatar, etc.). Upload returns the user-rooted path to pass to a later delete action; delete is idempotent. api plugin 1.0.38+ refuses `.md` and CSS files unless the blueprint field allows them via `allow_extensions`, and under user/accounts/ only the avatar of the calling account can be deleted without api.users.write. [Requires: api.media.write]
Create, rename, or delete a subfolder in the site media directory, or set the display order of files within one. For rename, provide both the current path and the new path. For order, provide "order" as the filenames in the desired order ("path" "" means the media root); an empty list removes the custom order. [Requires: api.media.write]
Install, remove, or update packages. "update" updates one named package; "update_all" updates every installed plugin and theme; "upgrade_grav" self-upgrades the Grav core itself. [Requires: api.gpm.write]
Revert configuration to inherited values. `keys` drops those overrides from the scope's file in the targeted layer (environment or base user/config); `reset` deletes the whole override file so the scope falls back to the parent layer and shipped defaults. The system, security, plugins/api, scheduler and backups scopes need a super-admin. Returns the resulting effective config with an etag. [Requires: api.config.write]
Search the GPM repository for available plugins and themes to install. [Requires: api.gpm.read]
Update configuration values for a scope. Writes are differential — only keys that differ from parent defaults persist. `environment` targets an existing user/env/ folder (see `manage_environments`); pass `etag` from `get_config` for conflict detection. [Requires: api.config.write]
Upload media files. Give "route" to attach the files to that page; leave "route" out to upload into the site media library, where "path" names an optional subfolder. Each file needs a filename and base64-encoded content. Supports images, videos, documents, and other file types. [Requires: api.media.write]
Parameter descriptions lack format/constraint details. 'filename' in upload_media and manage_blueprint_file has no stated length limits, character restrictions, or allowed extensions. 'path' in list_media and manage_media_folder lacks examples of valid formats (e.g., 'images/2024' vs 'images/2024/' vs absolute paths).
Tool disambiguation weak. manage_blueprint_file, upload_media, and manage_media_folder all handle file operations but serve different scopes (blueprint fields vs site media vs page media). Descriptions do not clearly explain when to use each, LLMs may conflate them.
Idempotency not declared. Tools like delete_media and manage_media_folder (delete action) state they are idempotent in descriptions, but tool annotations (idempotentHint) are not visible in schema. Agents cannot reliably detect safe retry behavior.