Skip to main content
Glama
Knuckles-Team

CISO Assistant MCP Server

Api question choices create

ciso_assistant_api_question_choices_create

Create a question choice via API to define selectable answers for compliance questionnaires and risk assessments.

Instructions

API endpoint for QuestionChoice CRUD.

Input Schema

NameRequiredDescriptionDefault
bodyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.3.6

TDQS

D1.6/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, idempotentHint=false, destructiveHint=false and openWorldHint=true, so safety is covered structurally. The description adds nothing beyond that: no note on required payload fields, what gets persisted, how the choice links to its parent Question, or error behavior for non-idempotent retries.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no padding, but brevity here comes from under-specification rather than discipline. Nothing is front-loaded because there is nothing substantive to front-load.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness1/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a mutation endpoint with an opaque free-form body, no output schema, and no parameter documentation, the description leaves an agent unable to construct a valid call or predict the effect. Annotations cover only the safety profile; everything else is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole 'body' parameter is an untyped object with 0% schema description coverage, and the description provides no indication of what fields belong in it. With a low-coverage schema the description is required to compensate, and it does not.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

Names the resource (QuestionChoice) but describes it as generic 'CRUD', which does not distinguish this create endpoint from the sibling list/retrieve/update/destroy tools. The name says 'create' but the description never states that a new choice is created.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance whatsoever, and no mention of alternatives such as question_choices_update or question_choices_partial_update. Calling it a 'CRUD' endpoint actively suggests it may serve read/update/delete purposes, which is misleading for a create-only route.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools