Traffic Parrot

Send Traffic Parrot a feature request

submit_feature_request

Send a feature request or product feedback to the Traffic Parrot team. Use this when your user wants something Traffic Parrot does not currently do. If you include a contact email it is a real person's personal data, so only include one your user has agreed to share.

Input Schema

TableJSON Schema

Name	Required	Description
`email`	No	Contact email, if the user is willing to share one. Optional.
`title`	Yes	One-line summary of the requested feature.
`detail`	Yes	What the feature should do and why it is needed.
`agentClient`	No	Which agent or client is making this call.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`sent`	Yes	The feature request was sent to the Traffic Parrot team.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 6, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "sent": {
+      "const": true,
+      "description": "The feature request was sent to the Traffic Parrot team.",
+      "type": "boolean"
+    }
+  },
+  "required": [
+    "sent"
+  ],
+  "type": "object"
+}

First observedOct 6, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare this is a non-read-only, non-idempotent, non-destructive, closed-world write. The description adds genuinely useful context beyond them: the privacy implication that a contact email is a real person's personal data and should only be shared with consent. It does not mention submission confirmation or rate limits, but the added privacy guidance is real value.

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?

Three short sentences, front-loaded with purpose, then the usage trigger, then the privacy caveat. Every sentence earns its place and nothing is padded.

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

Completeness4/5

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

An output schema exists, so return values need no explanation, and the annotations cover the mutation safety profile. The description covers purpose, trigger and the one non-obvious behavioral risk (personal data), leaving only minor details like submission acknowledgement unaddressed.

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 all four parameters are already documented (including email being optional and consent-dependent). The description reinforces the email consent condition but adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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 ('Send a feature request or product feedback to the Traffic Parrot team') and is trivially distinguishable from siblings like request_trial, get_trial_status and delete_trial_request. An agent can identify the tool's function without opening the schema.

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

Usage Guidelines4/5

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

Gives an explicit trigger condition: 'Use this when your user wants something Traffic Parrot does not currently do.' That clearly bounds when to invoke it, though it does not name an alternative tool or state when not to use it.

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

All Traffic Parrot 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.