Edit a question. Changing question_type will require resupplying options or correct_answer to match the new type.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ||
| points | No | ||
| options | No | ||
| sort_order | No | ||
| explanation | No | ||
| question_text | No | ||
| question_type | No | ||
| correct_answer | No |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does reveal an important constraint about the interdependence of question_type, options, and correct_answer. However, it does not mention whether updates are partial or full, how validation errors are handled, or what the response format is, leaving significant behavioral unknowns.
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 two concise sentences with no filler. The key action ('Edit a question') is front-loaded, and the extra note about question_type is directly relevant. Every sentence earns its place.
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 8 parameters, no output schema, and no annotations, the description is notably incomplete. It addresses only one behavioral relationship and omits essential context such as required fields, return value, error handling, and the effect of updating individual fields. A typical agent would have many unanswered questions when invoking this tool.
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 input schema has 0% description coverage, so the description must compensate. It adds meaningful semantics by explaining that changing question_type requires resupplying options and/or correct_answer, which clarifies those parameter relationships. But it does not explain id, points, sort_order, explanation, or question_text, leaving most parameters underdocumented.
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 opens with 'Edit a question,' which is a clear verb+resource pairing. While 'question' is somewhat generic, the tool name and sibling context (e.g., create_quiz_question, update_quiz) make it clear this targets quiz questions, distinguishing it from other update tools.
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?
The description provides a key usage hint ('Changing question_type will require resupplying options or correct_answer...'), which implies when to use this tool along with a special caution. However, it does not explicitly state when to choose this over alternatives like create_quiz_question or list_quiz_questions, nor does it mention any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Every tool targets a distinct resource/action combination, and similar-looking tools are carefully differentiated in descriptions (e.g., get_course_structure vs list_course_modules, update_lesson vs update_lesson_content). There is no meaningful overlap or ambiguity between tools.
All tools use a consistent 'hivelearn_<verb>_<noun>' pattern with common verbs (get, list, create, update). The only minor deviation is 'add' vs 'create' (add_track_course vs create_track), but this is semantically appropriate and does not disrupt the overall pattern.
With 57 tools, the server is significantly over the recommended range and exceeds the 25+ threshold for 'too many'. While the broad domain (courses, community, analytics) justifies a large surface, this many tools makes selection overwhelming for agents and suggests a need for consolidation or sub-servers.
The tool surface covers create, read, and update for most core entities (courses, lessons, quizzes, tracks, posts, events, resources), plus publishing/verification and analytics. However, there are notable gaps: no delete operations for courses, lessons, modules, quizzes, posts, events, resources, or enrollments, and no way to remove a course from a track. These lifecycle holes are significant but not fatal for common workflows.
