SEO GSC Wizard MCP

Grant or revoke report access

manage_report_access

Destructive

Grants or revokes client access to a saved shareable report. This is what makes a report openable at all: an ungranted report opens for nobody, including the account owner. After granting, the client opens the report URL, enters their email, and GSC Wizard emails them a login link. That self-serve sign-in only works once they hold a grant. Clients must already exist on the account: add them with create_report_client, find ids with list_report_clients. NOTE: unlike the web app's share dialog, this tool does NOT itself send a "report shared with you" notification. Either pass the recipient the report URL, or send the notification from Account > Shared Reports in GSC Wizard (https://tool.gscwizard.com/account/shared-reports), where each client has a Resend button. OWNER CONFIRMATION: granting to a client who has never been sent a report from this account does NOT give access yet. The grant stays pending and GSC Wizard emails the account owner a link to confirm or cancel it; until the owner confirms, the recipient cannot open the report or sign in to the portal. Such clients are listed in pendingConfirmation, not granted. Tell the user to check their email. Clients who already hold a confirmed grant are granted at once. action "revoke" withdraws access (pending grants included). Granting is idempotent: a client who already had access stays granted and is reported as unchanged.

Input Schema

Name	Required	Description
`action`	Yes
`reportId`	Yes
`clientIds`	Yes	Client ids from list_report_clients / create_report_client.

Output Schema

Name	Required	Description	Default
`url`	No
`note`	No
`action`	No
`granted`	No
`revoked`	No
`reportId`	No
`emailsSent`	No
`reportTitle`	No
`alreadyHadAccess`	No
`didNotHaveAccess`	No
`unknownClientIds`	No
`pendingConfirmation`	No
`ownerConfirmationEmailSent`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedOct 24, 2026
- addedOutput schema / properties / ownerConfirmationEmailSent
```
Added value: +{
+  "type": [
+    "boolean",
+    "null"
+  ]
+}
```
- addedOutput schema / properties / pendingConfirmation
```
Added value: +{
+  "$ref": "#/properties/granted"
+}
```
Changed1 schema field changedOct 18, 2026
- changedOutput schema / additionalProperties
```
Previous value: -falseNew value: +true
```
First observedOct 7, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description adds substantial non-obvious behavior: the owner-confirmation gate for first-time grants, the pendingConfirmation status, the fact that unconfirmed recipients cannot open the report or sign in, revoke covering pending grants, and grant idempotency with an 'unchanged' result. This is exactly the kind of state-machine context an agent needs before mutating access.

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-loads the core action and the critical 'ungranted opens for nobody' constraint, then layers conditions. Dense and largely earned, though the URL plus Resend-button walkthrough and repeated confirmation framing run longer than strictly necessary.

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?

For a destructive, open-world mutation with an existing output schema, the description covers prerequisites, failure modes, the confirmation flow, and result semantics (pendingConfirmation, unchanged) thoroughly enough that an agent can call it 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 low (33%), so the description must compensate; it does for action (grant vs revoke semantics, pending included, idempotency) and indirectly for clientIds via the sibling tools it names. reportId is only implied as the target report via the opening sentence, so it is slightly less explicit than the other parameters.

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 pair ('grants or revokes') on a specific resource ('client access to a saved shareable report'), and explicitly names the related siblings create_report_client and list_report_clients with their distinct roles. An agent can distinguish it from create_shared_report or list_shared_reports 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 preconditions ('Clients must already exist on the account'), routes to the right siblings for creating/finding client ids, and warns that unlike the web share dialog this tool does NOT send a notification, with concrete alternatives (pass the URL, Resend from the account UI). Covers both grant and revoke behavior and idempotency.

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

All SEO GSC Wizard MCP 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?