PickFu

rate_response

DestructiveIdempotent

Marks an individual respondent comment as helpful or not_helpful. Use this after get_survey_responses to programmatically curate response quality — e.g. flag low-effort or off-topic responses for downstream filtering.

IMPORTANT: rating a response 'not_helpful' is destructive. It counts against a per-survey flag cap: free (pay-as-you-go) owners may flag 10% of the sample size, rounded up (e.g. 3 flags on a 30-response survey) — or 30% of the sample size with a floor of 2 on screen-recording polls; trial owners use the same limit. Non-trial PickFu+/Enterprise subscribers have no cap. The cap is per survey, not a fixed number, so do not quote one without knowing the sample size and plan. Exceeding it returns an error. Within the cap it auto-rejects the response (and, on multi-question surveys, all responses from the same respondent), recalculates the survey's valid-answer count, and may reopen a completed survey to collect replacement responses. Confirm with the user before applying 'not_helpful' to multiple responses in bulk.

Switching a previous 'not_helpful' rating to 'helpful' records the new vote but does NOT un-reject the response that was auto-rejected by the prior flag. Re-rating without re-sending the comment field preserves the previous comment.

Input Schema

Name	Required	Description
`rating`	Yes	Rating to apply. 'helpful' marks the response as high-quality. 'not_helpful' flags it as low-quality and may auto-reject the response — see tool description for full effect.
`comment`	No	Optional reason or note attached to the rating (max 500 chars).
`surveyId`	Yes	The parent survey id returned with this response.
`responseId`	Yes	The response ID (GUID) returned in the `id` field of get_survey_responses.
`idNamespace`	No	Identifier namespace. Omit for historical/canonical lookup; choose canonical or legacyGuid to disambiguate an owned collision. legacyNumber uses a positive decimal database id.

Output Schema

Name	Required	Description	Default
`data`	No
`success`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedNov 4, 2026

addedInput schema / properties / idNamespace

Added value: +{
+  "description": "Identifier namespace. Omit for historical/canonical lookup; choose canonical or legacyGuid to disambiguate an owned collision. legacyNumber uses a positive decimal database id.",
+  "enum": [
+    "canonical",
+    "legacyGuid",
+    "legacyNumber",
+    "unclassified"
+  ],
+  "type": "string"
+}

addedInput schema / properties / responseId

Added value: +{
+  "description": "The response ID (GUID) returned in the `id` field of get_survey_responses.",
+  "pattern": "^[A-Za-z0-9_-]{1,64}$",
+  "type": "string"
+}

removedInput schema / properties / response_id

Removed value: -{
-  "description": "The response ID (GUID) returned in the `id` field of get_survey_responses.",
-  "pattern": "^[A-Za-z0-9_-]{1,64}$",
-  "type": "string"
-}

addedInput schema / properties / surveyId

Added value: +{
+  "description": "The parent survey id returned with this response.",
+  "minLength": 1,
+  "type": "string"
+}

changedInput schema / required

Previous value: -[
-  "response_id",
-  "rating"
-]New value: +[
+  "surveyId",
+  "responseId",
+  "rating"
+]

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations flag destructiveHint and idempotentHint, but the description goes far beyond them: per-plan flag caps with tier-specific math, error on cap exceedance, cascade rejection of all responses from the same respondent, valid-answer recalculation, possible survey reopening, and the irreversibility of auto-rejection when flipping not_helpful back to helpful. This is exactly the kind of consequence detail an agent needs before a destructive call.

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?

Front-loaded with purpose, then routing, then a clearly marked IMPORTANT block of consequences; the cap arithmetic examples ('3 flags on a 30-response survey') aid comprehension rather than pad. It is dense but long, and the plan-tier enumeration could be tightened slightly without losing meaning.

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

Completeness5/5

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

With annotations covering safety, a full output schema, and 100% parameter description coverage, the description supplies the remaining behavioral context (caps, cascades, reversibility) needed for a destructive multi-tier operation. Nothing required to call it correctly is missing.

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?

Schema coverage is 100% so the baseline is 3, but the description adds real semantics for the comment field ('Re-rating without re-sending the comment field preserves the previous comment') and clarifies that 'helpful' simply marks quality while 'not_helpful' triggers auto-rejection. idNamespace is left to the schema, which is acceptable given its own description.

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?

States a specific verb and resource ('Marks an individual respondent comment as helpful or not_helpful') and anchors it to the sibling it follows from, get_survey_responses. An agent can distinguish it from pin_response or semantic_search_answers without opening any schema.

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

Usage Guidelines5/5

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

Gives explicit sequencing ('Use this after get_survey_responses to programmatically curate response quality'), names concrete use cases (flagging low-effort or off-topic responses), and adds a clear when-not/caution rule ('Confirm with the user before applying not_helpful to multiple responses in bulk').

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

All PickFu tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?