unprotectRemoves the passcode or invite-only setting from a whole site or the protection from one path (owner; returns approve_url). Each protected path opens on its own.
| Name | Required | Description | Default |
|---|---|---|---|
| path | No | "/" (default, whole site) or a protected part such as /students | |
| site | Yes | ||
| confirm_token | No |
| Name | Required | Description | Default |
|---|---|---|---|
| protected | No | ||
| approve_url | No | ||
| members_only | No | ||
| agent_message | No | ||
| confirm_token | No |
Changes observed during successful MCP inspections.
Output schema / properties / agent_messageAdded value: +{
+ "type": "string"
+}Output schema / properties / approve_urlAdded value: +{
+ "type": "string"
+}Output schema / properties / members_onlyAdded value: +{
+ "type": "boolean"
+}Output schema / properties / protectedAdded value: +{
+ "type": "boolean"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "confirm_token": {
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / confirm_token / descriptionRemoved value: -"From the first call"Input schema / properties / confirm_token / descriptionPrevious value: -"From the first call: approval status"New value: +"From the first call"Input schema / properties / site / descriptionRemoved value: -"Site name"Input schema / properties / confirm_token / descriptionPrevious value: -"From the first call: re-call with it for the approval status"New value: +"From the first call: approval status"Input schema / properties / site / descriptionPrevious value: -"Site name, e.g. brave-otter-4821"New value: +"Site name"Output schema / (root)Previous value: -{
- "additionalProperties": {},
- "properties": {
- "agent_message": {
- "type": "string"
- },
- "confirm_token": {
- "type": "string"
- },
- "error": {
- "description": "On failure (isError): {code, message}"
- }
- },
- "type": "object"
-}New value: +nullDoes the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and openWorldHint=true, so the description only needs to add context — it does: owner-level auth is required and an approve_url is returned, implying the removal may go through an approval flow rather than applying instantly. It stops short of stating whether the removed passcode is recoverable or what happens to already-authenticated visitors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with the action front-loaded and the scope/auth/return facts packed in. 'Each protected path opens on its own' is slightly telegraphic and could be phrased more plainly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 only 33% schema coverage, key operational facts are absent: the origin of confirm_token, whether the returned approve_url must be visited to complete the change, and whether the operation is reversible. The output schema exists, so return-value detail is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, so the description must compensate. It does explain the path/site dichotomy (whole site vs. one protected part, matching the '/'-default in the schema), but confirm_token — arguably the most opaque parameter — is never mentioned, leaving the agent to guess how it is obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific verb ('removes') and object ('passcode or invite-only setting' / 'protection from one path'), and clarifies two scopes: whole site vs. a single path. It does not explicitly reference the inverse sibling 'protect' or 'site_settings', which would have made the differentiation airtight.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'(owner; ...)' states the permission prerequisite, and 'Each protected path opens on its own' warns the agent that unprotecting the site will not clear per-path protection, so repeated per-path calls may be required. No explicit when-not or named alternative is given, but the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.