Skip to main content
Glama
Sign In
surveymonkey-mcp

surveymonkey-mcp

by dscovr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

surveymonkey_create_page

Add a new page to an existing survey by providing the survey ID and optional title, description, or position. Organize survey flow with structured pages.

Instructions

Creates a new page in a survey.

Args: survey_id: Survey ID. payload: Page definition. Structure: { "title": "Page title", (optional) "description": "Description", (optional) "position": 1 (optional) }

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "survey_id": "<survey_id>",
      "payload": "<payload>"
    },
    "name": "surveymonkey_create_page"
  }
}

Input Schema

NameRequiredDescriptionDefault
payloadYes
survey_idYes

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.5/5.0
Behavior2/5

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

There are no annotations, so the description carries the full behavioral burden. It only states that a page is created and documents payload fields; it does not disclose prerequisites, side effects, validation behavior, or permissions.

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

Conciseness5/5

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

The description is short, front-loaded with the core purpose, and uses a compact code block for the payload structure. Every sentence and line earns its place.

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

Completeness3/5

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

The output schema covers return values, so that omission is acceptable. However, the description lacks usage-vs-alternatives guidance and behavioral caveats, leaving some uncertainty for an agent deciding among page CRUD tools.

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

Parameters4/5

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

The input schema is nearly empty (0% description coverage), and the description compensates by clarifying survey_id and providing a structured payload example with optional fields. It does not fully specify types or constraints for each nested field, but is meaningfully helpful.

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

Purpose5/5

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

The description starts with a specific verb and resource: 'Creates a new page in a survey.' This clearly distinguishes it from page-update, page-delete, and page-list sibling tools without needing to inspect schemas.

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 description states what the tool does but provides no guidance about when to use it versus alternatives, no prerequisites, and no exclusions. An agent must infer usage from the tool name and sibling list.

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