Skip to main content
Glama
RVAILab

Profile Questions MCP Server

by RVAILab

submit_answer

Send an answer to a profile question, matching the response type to the question type so profile data stays accurate.

Instructions

Submit an answer to a profile question. The answer type must match the question type.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textValueNoFor free_form or fill_in_blank questions: the text answer (max 5000 chars)
questionIdYesUUID of the question to answer
answerSourceYesThe source/app submitting the answer
booleanValueNoFor yes_no questions: true or false
selectedOptionsNoFor multiple_choice questions: array of selected option(s)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description bears the full burden of behavioral disclosure. It doesn't state what happens on submission (e.g., whether answers are finalized, persisted, editable, or trigger scoring), nor any error behavior if the answer type mismatches. The single constraint about type matching is a fragment of what's needed for a mutation tool.

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

Conciseness4/5

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

Two short sentences with no waste, and the core action is front-loaded. It could be slightly more informative without losing conciseness, but brevity is not a flaw here.

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

Completeness2/5

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

For a mutation tool with no annotations and no output schema, the description is too sparse. It omits the return/confirmation behavior, error handling for type mismatches, and the relationship to batch_submit_answers, leaving the agent to infer important invocation context.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents each parameter including which value field maps to which question type. The description adds no meaning beyond the schema, so baseline 3 is appropriate.

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

Purpose4/5

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

The description states a clear verb and resource: 'Submit an answer to a profile question.' It distinguishes itself from retrieval siblings like get_my_answers and list_questions, and from batch_submit_answers by being singular. However, it doesn't explicitly mention batching as an alternative, which is where differentiation would be strongest.

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

Usage Guidelines2/5

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

The only guidance is 'The answer type must match the question type,' which is a constraint rather than a when-to-use/when-not-to-use statement. It does not mention batch_submit_answers as an alternative for multiple answers, nor does it explain how to determine which answer field to populate beyond a subtle type hint.

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