Loading ToolBench
MCP server for governance, dynamic content management, block composition, and role-based access control
Smeldr MCP provides 17 tools with complete JSON Schema input definitions and detailed descriptions (avg 180 chars). Naming follows verb_noun convention (get_, create_, list_, update_, set_, add_, remove_, grant_, revoke_). However, output schemas are not documented, responses are inferred from code (e.g., get_check_status returns {found, subject_type, subject_id, rule_type, ran_at, match_type, match_id, match_name, sentence}). Parameter descriptions are present but inconsistent in depth. Error handling is basic (jsonRPCError with code/message) and lacks recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (READ_ONLY, WRITE, DESTRUCTIVE). Security-sensitive tools (grant_role, revoke_grant) lack explicit permission documentation in descriptions.
Append a block as the last item of a collection. Requires Editor role.
Append a block as the last section of a page. Requires Editor role.
Create a Draft item of the given runtime content type. Returns the new item with its ID and slug. Requires Editor role.
Define a new runtime content type by providing its schema. type_name must be unique and lower_snake_case. fields is a JSON array of {name, type, required, format, role} objects. url_prefix sets the public URL prefix (e.g. "/recipes"); omit or leave empty for admin-only types. Requires Admin role.
Read the most recently recorded Check result for a subject (smeldr.CheckStore.Last) — whether an Authority-graph conflict was found on ratification, the matched Rule/AuthorityStub if any, and the pre-computed comparison sentence. found is false when Check has never run for this subject — a real, computed answer, not a failure. Requires Author role.
Output schemas not documented. Tool descriptions state what is returned (e.g., 'Returns the new item with its ID and slug') but formal response schemas are absent. LLMs cannot plan downstream tool calls or extract fields reliably.
Tool annotations missing. Tools are marked with Risk levels (READ_ONLY, WRITE, DESTRUCTIVE) in metadata but not exposed as readOnlyHint, destructiveHint, or idempotentHint in the MCP tool definition. Agents cannot distinguish safe from destructive operations.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
Get a single content item by type name and slug, at any lifecycle status. Requires Author role.
Grant a governance role to a token. Requires Admin role. Distinct from a token's legacy role field: this is an explicit, separately-audited authorization act (D43).
List content items of the given type. Supports pagination and status filter. Requires Author role.
List governance role grants. Requires Admin role. Omit token_id to list every grant on the instance.
Remove an item from a collection. Requires Editor role.
Remove a section from a page. Requires Editor role.
Reorder a collection's items to match the given order. Requires Editor role.
Reorder a page's sections to match the given order. Requires Editor role.
Revoke a governance role grant by its own ID (from list_grants), not by token ID. Requires Admin role.
Schedule a content item for future publication. Sets status to scheduled and records the scheduled_at time. Requires Editor role.
Transition a content item to draft, published, archived, or scheduled. Published items get PublishedAt stamped on first transition. Use schedule_content to set a future publication time. Requires Editor role.
Patch the fields of an existing content item by ID. Absent keys are preserved (partial update). Requires Editor role.
Error handling lacks recovery guidance. jsonRPCError responses include code and message but no actionable next steps. E.g., 'invalid params: subject_type required' does not suggest what valid values are or how to recover.
Permission requirements not explicit in tool descriptions. grant_role, revoke_grant, and list_grants require Admin role; define_content_type requires Admin; others require Author or Editor. Descriptions mention role requirements but do not explain what permissions the agent needs or how to request them.
Parameter descriptions inconsistent in depth. get_check_status has clear descriptions ('e.g. "Decision"'); add_section/remove_section/add_item/remove_item have minimal descriptions ('ID of the parent block or content instance'). Inconsistency reduces LLM clarity on parameter semantics.