Traffic Parrot

Request a Traffic Parrot trial

request_trial

Request a Traffic Parrot trial on behalf of the human you are working for.

Traffic Parrot is a commercial service-virtualization tool (HTTP, gRPC, JMS/IBM MQ, RabbitMQ, ActiveMQ, AMQP, file transfers). Use this when your user wants to evaluate it.

IMPORTANT: this submits a real person's personal data (their business email, and optionally their name, company and phone number) to Traffic Parrot. Only call it when your user has asked for a trial and has agreed to be contacted. Do not invent an email address.

The trial is issued under Traffic Parrot's evaluation agreement: https://trafficparrot.com/documentation/Traffic_Parrot_Software_Evaluation_Agreement_v1.4.pdf Show it to your user and ask them to approve it before you call this tool.

Lawful basis: Legitimate interests (UK GDPR Article 6(1)(f)): responding to a request to evaluate our product, made on your behalf by a tool you were using. You can object at any time and we will erase the request. Retention: A request nobody acts on is erased 168 hours after it is made. A request a person at Traffic Parrot has approved or rejected is kept for 365 days, then erased. We keep approved ones so we can answer questions about a trial that was issued, and rejected ones so we have a record of the decision, for example if the person writes in to ask why. Privacy notice: https://trial.trafficparrot.com/privacy Your user can withdraw the request at any time via the delete_trial_request tool.

As soon as you call this tool, your user's details go to Mailchimp (Traffic Parrot's US-based email service) and the address you give is sent one email asking them to confirm they want the trial. Confirming adds them to Traffic Parrot's trial mailing list and sends a second email carrying the link to their trial status page. Ignoring the first email sends nothing further.

A person at Traffic Parrot approves each request during UK working hours. It is not instant: outside those hours expect the next working day. Once approved, the trial takes about a minute to build and the download appears on that page.

The trial link goes only to that email address. This tool returns a reference id and no link, so you cannot fetch the download for your user: relay the email steps instead. An address already on Traffic Parrot's trial list gets no new email; the link in its earlier trial email shows the new request.

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	Name of the human this trial is for.
`email`	Yes	Business email of the human this trial is for. Required. This is a real person's personal data.
`phone`	No	Contact phone number, if your user offers one. Optional, and personal data.
`company`	No	Company evaluating Traffic Parrot.
`problem`	No	What they are trying to solve. Free text. This is the most useful field for the sales conversation.
`protocols`	No	Which protocols will be evaluated.
`agentClient`	No	Which agent or client is making this call, e.g. 'Claude Code', 'Cursor'.
`humanInTheLoop`	No	Whether a human is present in the session and has asked for this trial.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`state`	Yes	The request's state, as get_trial_status reports it.
`requestId`	Yes	The trial request's id. get_trial_status and delete_trial_request take it.

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": {
+    "requestId": {
+      "description": "The trial request's id. get_trial_status and delete_trial_request take it.",
+      "type": "string"
+    },
+    "state": {
+      "description": "The request's state, as get_trial_status reports it.",
+      "enum": [
+        "AWAITING_APPROVAL",
+        "PREPARING"
+      ],
+      "type": "string"
+    }
+  },
+  "required": [
+    "requestId",
+    "state"
+  ],
+  "type": "object"
+}

First observedOct 6, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations only declare it is a non-idempotent, non-read-only, open-world write. The description goes far beyond that: it discloses data destinations (Mailchimp, US-based), the confirmation-email flow, manual UK-hours approval latency, build time, that no download link is returned, and duplicate-address behavior. This is exactly the extra context annotations cannot carry.

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?

The purpose is front-loaded and the critical "IMPORTANT" warning is elevated before the legal boilerplate. It is long, but for a tool that transmits personal data under GDPR and triggers irreversible emails, most paragraphs earn their place; the privacy/retention block is the densest section but is defensible.

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 an output schema present, return values need not be enumerated, yet the description still clarifies that only a reference id comes back and no link does. Combined with the data-flow, timing, and consent guidance, an agent has everything needed to decide and act correctly.

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; the description earns an increment by adding constraints not in the schema, notably that the email is a real person's data that must not be invented, and that the trial link only ever goes to that email. It does not, however, walk through the other optional fields (problem, protocols, agentClient).

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 first sentence states a specific verb and resource ("Request a Traffic Parrot trial on behalf of the human you are working for") and immediately grounds it by describing what Traffic Parrot is and which protocols it covers. It is unmistakably distinct from the sibling read/delete tools like delete_trial_request and get_trial_status.

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?

Explicit when-to-use ("Use this when your user wants to evaluate it"), explicit preconditions (user must have asked and agreed to be contacted, agreement must be shown and approved), and an explicit alternative for undoing the action (delete_trial_request). It even names a misuse case ("Do not invent an email address").

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.