Opus Growth, Ad Platforms MCP Connector

Report Issue

report_issue

Reports a bug or unexpected failure to Opus Growth support: pass a short summary, the failing tool_name, and any error details. The user is emailed when the issue is resolved. title, description and text are accepted as synonyms of summary/details, so a report is never lost to a parameter-name mismatch.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`text`	No
`title`	No
`details`	No
`summary`	No
`tool_name`	No
`description`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedSep 20, 2026
- addedInput schema / properties / description
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
- addedInput schema / properties / summary / default
```
Added value: +""
```
- addedInput schema / properties / text
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
- addedInput schema / properties / title
```
Added value: +{
+  "default": "",
+  "type": "string"
+}
```
- removedInput schema / required
```
Removed value: -[
-  "summary"
-]
```
First observedSep 16, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already mark this as non-read-only and non-destructive, and the description adds useful behavioral context: the user receives an email on resolution, and synonyms are accepted to prevent lost reports. This goes beyond the annotation fields without contradicting them.

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?

Two compact sentences lead with the purpose, then cover required parameters and edge-case aliases. There is no fluff; the extra explanation about synonyms earns its place.

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?

For a simple reporting tool, the description covers purpose, parameters, aliases, and side effects. It doesn't explain whether at least one of summary/details is expected, but the output schema and annotations cover the remaining context, so this is a minor gap.

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?

With 0% schema description coverage, the description carries the full burden and does compensate: it explains summary, tool_name, details, and all three synonyms. It is slightly vague about which synonyms map to which field, but it still meaningfully documents every parameter.

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 uses a specific verb ('Reports') and names the exact resource ('a bug or unexpected failure to Opus Growth support'), which makes the tool's job unmistakable. The content is clearly distinct from sibling tools like get_report or call_tool even without naming them.

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?

The description clearly states the intended trigger (bug or unexpected failure) and how to structure the report (summary, tool_name, details). It does not explicitly contrast with alternatives or give negative guidance, but the use case is clear enough.

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

All Opus Growth, Ad Platforms MCP Connector 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.