Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Profile Questions MCP Server list my unanswered profile questions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that allows AI agents to interact with the White Rabbit Profile Questions API. This enables agents to create questions, submit answers, and query existing profile data.
cd mcp-servers/profile-questions
npm install
npm run buildRelated MCP server: Futurykon MCP Server
Set the following environment variables:
Variable | Description | Default |
| Base URL of the White Rabbit API |
|
| API key for authentication | (none) |
Add to your Claude Desktop config (~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"profile-questions": {
"command": "node",
"args": ["/path/to/mcp-servers/profile-questions/dist/index.js"],
"env": {
"PROFILE_QUESTIONS_API_URL": "https://your-api-url.com",
"PROFILE_QUESTIONS_API_KEY": "your-api-key"
}
}
}
}List profile questions by source.
Parameters:
source (required): profile_optimizer | admin | onboarding | survey
category (optional): Filter by category
questionType (optional): free_form | multiple_choice | yes_no | fill_in_blank
activeOnly (optional): Only return active questions (default: true)
page (optional): Page number (0-indexed)
limit (optional): Items per page (default: 50)
Create a new profile question.
Parameters:
questionText (required): The question text (1-500 characters)
questionType (required): free_form | multiple_choice | yes_no | fill_in_blank
source (required): profile_optimizer | admin | onboarding | survey
description (optional): Description for the question (max 1000 characters)
options (required for multiple_choice): Array of at least 2 options
allowMultiple (optional): Allow selecting multiple options (default: false)
fillInBlankTemplate (required for fill_in_blank): Template containing {blank} placeholder
category (optional): Category for organizing questions (max 100 characters)
displayOrder (optional): Order for displaying questions (default: 0)
isActive (optional): Whether the question is active (default: true)
Get the current user's answers to profile questions.
Parameters:
source (optional): Filter answers by source
Submit an answer to a profile question.
Parameters:
questionId (required): UUID of the question to answer
answerSource (required): profile_optimizer | admin | onboarding | survey
textValue (optional): For free_form or fill_in_blank questions
booleanValue (optional): For yes_no questions (true/false)
selectedOptions (optional): For multiple_choice questions
Submit multiple answers at once (up to 50).
Parameters:
answers (required): Array of answer objects (same structure as submit_answer)
Type | Answer Field | Description |
|
| Open-ended text responses |
|
| Select from predefined options |
|
| Binary true/false |
|
| Complete a sentence template |
{
"tool": "create_question",
"arguments": {
"questionText": "What is your experience level with AI tools?",
"questionType": "multiple_choice",
"options": ["Beginner", "Intermediate", "Advanced", "Expert"],
"source": "profile_optimizer",
"category": "skills"
}
}{
"tool": "submit_answer",
"arguments": {
"questionId": "123e4567-e89b-12d3-a456-426614174000",
"selectedOptions": ["Advanced"],
"answerSource": "profile_optimizer"
}
}{
"tool": "batch_submit_answers",
"arguments": {
"answers": [
{
"questionId": "uuid-1",
"selectedOptions": ["Advanced"],
"answerSource": "profile_optimizer"
},
{
"questionId": "uuid-2",
"textValue": "I have 5 years of experience",
"answerSource": "profile_optimizer"
}
]
}
}# Watch mode for development
npm run dev
# Build for production
npm run build
# Run the server
npm startThe server uses bearer token authentication. Set your API key via the PROFILE_QUESTIONS_API_KEY environment variable. The key is passed in the Authorization header as Bearer <key>.
Submit multiple answers at once (up to 50). Useful for completing questionnaires.
| Name | Required | Description | Default |
|---|---|---|---|
| answers | Yes | Array of answers to submit (1-50 items) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full behavioral burden. It discloses the 50-item cap but nothing about atomicity (does one bad answer fail the whole batch?), validation behavior, partial success, or required permissions for a mutation operation.
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?
Two short, front-loaded sentences with no waste. The limit is stated immediately after the verb, which is the right emphasis.
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?
A batch mutation tool with no annotations, no output schema, and no disclosure of atomicity, validation, or failure semantics. An agent cannot predict what happens when one answer in the array is invalid, which is critical for a write operation.
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?
Schema coverage is 100% and the schema fully documents the nested answer structure, including per-type fields. The description only restates the batch limit, adding nothing beyond the schema. Baseline 3 is appropriate.
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?
States a specific verb (submit) and resource (answers), plus the batch scope ('multiple at once, up to 50'). Distinguishes itself from the singular sibling submit_answer via 'multiple', though it doesn't name it or explicitly contrast.
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?
'Useful for completing questionnaires' implies a context but gives no when-to-use vs when-to-prefer the singular submit_answer, no exclusions, and no guidance on error handling for batches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new profile question. Questions can be free-form text, multiple choice, yes/no, or fill-in-the-blank.
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | The source/app creating the question | |
| options | No | Required for multiple_choice: array of at least 2 options | |
| category | No | Optional category for organizing questions (max 100 characters) | |
| isActive | No | Whether the question is active (default: true) | |
| description | No | Optional description for the question (max 1000 characters) | |
| displayOrder | No | Order for displaying questions (default: 0) | |
| questionText | Yes | The question text (1-500 characters) | |
| questionType | Yes | The type of question | |
| allowMultiple | No | For multiple_choice: allow selecting multiple options (default: false) | |
| fillInBlankTemplate | No | Required for fill_in_blank: template containing {blank} placeholder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It conveys creation but omits permissions/auth needs, default behavior (isActive, displayOrder defaults), and any side effects. The type list is helpful but not behavioral disclosure.
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?
Two tight sentences with no filler and a clear front-loaded verb. It doesn't elaborate, but nothing is wasted.
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?
For a 10-parameter creation tool with no annotations and no output schema, the description is thin. It should at minimum note the conditional requirements for multiple_choice and fill_in_blank and any return/side-effect context, though the rich schema covers field-level semantics.
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?
Schema description coverage is 100%, and the schema already documents all 10 parameters including enum meanings and conditional requirements. The description only restates question types, adding no syntax or interaction detail beyond the schema. Baseline 3 applies.
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?
States a specific verb and resource ('Create a new profile question'), and enumerates valid question types, which aligns with the questionType enum. It doesn't distinguish from siblings, but create vs. list/get/submit is reasonably inferable from the verb.
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?
No when-to-use guidance or prerequisites. It doesn't state that options are required for multiple_choice or that fillInBlankTemplate is required for fill_in_blank, nor when to prefer this over related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current user's answers to profile questions. Requires authentication.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | Optional: filter answers by source |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the authentication requirement, which is genuinely useful, but says nothing about read-only nature (only implied by 'Get'), result shape, pagination, or behavior when no answers exist.
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?
Two brief sentences with the core purpose front-loaded and the precondition second; nothing is wasted.
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?
For a simple no-required-param read tool this is nearly adequate, but with no annotations and no output schema the description should at least hint at the return shape or whether it's scoped to the authenticated identity.
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?
Schema description coverage is 100% and the single 'source' parameter already documents its enum values and filtering role. The description adds no meaning beyond the schema, so the baseline of 3 applies.
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?
States a specific verb and resource: 'Get the current user's answers to profile questions.' This is clearly distinct from sibling tools like submit_answer and list_questions, though it doesn't name or explicitly contrast with any of them.
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 only guidance is a precondition ('Requires authentication'); there is no indication of when to use this versus list_questions or the submit_* alternatives, nor any exclusion conditions. Usage is only loosely implied by 'current user's answers.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List profile questions by source. Use this to discover available questions before submitting answers.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (0-indexed) | |
| limit | No | Items per page (default: 50) | |
| source | Yes | The source/app that created the questions | |
| category | No | Optional category to filter by | |
| activeOnly | No | Only return active questions (default: true) | |
| questionType | No | Optional question type to filter by |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly signals a read-oriented discovery operation, but says nothing about pagination behavior, default filtering (activeOnly defaults true), permission requirements, or the shape of results. Adequate but with clear disclosure gaps.
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?
Two short sentences with zero filler; the operation is front-loaded ahead of the usage hint. Every clause 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?
There is no output schema, but for a paginated list tool with fully documented parameters the description covers the essential who/what/why. The main omission is any mention of pagination or result-size behavior, which leaves a small gap.
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?
Schema description coverage is 100%, with every parameter documented including the source enum and filters, so the schema does the heavy lifting. The description's 'by source' only restates the required parameter and adds no format or semantics beyond the schema, making the baseline 3 correct.
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 states a specific verb and resource ('List profile questions') and adds the scoping dimension ('by source'), which maps directly to the required source enum. It does not explicitly contrast itself with siblings like get_my_answers, but the operation is unambiguous.
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?
'Use this to discover available questions before submitting answers' gives a concrete workflow context that positions it ahead of submit_answer. It stops short of naming alternatives or stating when not to use it (e.g. versus get_my_answers), so it is clear context without exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit an answer to a profile question. The answer type must match the question type.
| Name | Required | Description | Default |
|---|---|---|---|
| textValue | No | For free_form or fill_in_blank questions: the text answer (max 5000 chars) | |
| questionId | Yes | UUID of the question to answer | |
| answerSource | Yes | The source/app submitting the answer | |
| booleanValue | No | For yes_no questions: true or false | |
| selectedOptions | No | For multiple_choice questions: array of selected option(s) |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0batch_submit_answerscreate_questionget_my_answerslist_questionssubmit_answerScored across 5 tools
Each tool targets a distinct resource-action pair: get_my_answers (retrieve user answers), list_questions (discover questions), create_question (author questions), submit_answer (single answer), batch_submit_answers (bulk answers). The single vs. batch submit pair is clearly delineated, and questions vs. answers tools don't overlap.
All names follow a consistent snake_case verb_noun pattern: get_my_answers, list_questions, create_question, submit_answer, batch_submit_answers. The batch_ prefix is a predictable modifier rather than a convention break.
Five tools is well-scoped for a questionnaire/profile domain, with each tool earning its place across the read/create/answer lifecycle. Nothing feels redundant or missing at the count level.
Core lifecycle is covered: authoring questions, listing them, and submitting answers singly or in bulk. However, there is no update/delete for questions and no retrieval of a single question by id, which are minor gaps an agent can work around.
Automate 1,000+ services from any MCP-compatible AI agent: build Applets, run actions and queries.
Generate contextual prompts and reusable agent skills, evaluate prompts with the 16-dimension Prompt Score, and manage saved work in PromptDrive. Twelve MCP tools also provide authorized access to private Memory for source-grounded answers. Connect over Streamable HTTP using OAuth 2.1 and PKCE. Generation consumes account quota and automatically saves successful results; Memory access follows account permissions and plan limits.
Curated knowledge API for AI agents - skill packs, semantic search, validated patterns.
AI-native survey & form builder. Manage surveys, responses, analytics, and webhooks.
