Gooo policy and MCP change checks

Overview Schema Source Related Servers Discussions Admin

Check a service-grant narrowing

assess_service_grant

Read-onlyIdempotent

Assesses whether a narrower service grant is a supported subset of the previous grant and preserves the required service type and name, returning eligibility, refusal, or invalid input.

Instructions

Use when considering a narrower service grant that must preserve one required service request. Assesses whether after is a supported subset of before and still matches required_type and required_name. For an ordered request list, use assess_service_grant_change when available. Domain-invalid facts return INVALID_INPUT; malformed arguments return a tool error with no decision. Supplied facts are not authenticated; no grant or API operation is applied.

Input Schema

Name	Required	Description
`after`	Yes	Proposed replacement service-grant pattern, using the same syntax as before. It must be a supported subset and preserve the supplied required request(s) for ELIGIBLE. Do not normalize or repair an unsupported pattern to force eligibility.
`before`	Yes	Previous service-grant pattern, preserved exactly. Examples: * (all services), mcp://* (all MCP services), or mcp://weather (one service). Supported patterns use ASCII text of at most 128 bytes; paths, queries and fragments are outside this domain.
`required_name`	Yes	Exact required service name, for example weather, not an individual tool name or a path such as weather/forecast. Supported nonempty names contain ASCII letters, digits, - and _ in nonempty dot-separated labels, at most 128 bytes. Preserve the supplied spelling; Gooo decides domain validity.
`required_type`	Yes	Exact required service type, for example mcp or http; not a full URI. The supported domain is ASCII, at most 128 bytes, starting with a letter when nonempty, followed by letters, digits, +, - or .; Gooo decides domain validity.

Output Schema

Name	Required	Description	Default
`facts`	Yes
`bindings`	Yes
`decision`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv0.1.0-preview.3Oct 25, 2026

addedInput schema / properties / after / description

Added value: +"Proposed replacement service-grant pattern, using the same syntax as before. It must be a supported subset and preserve the supplied required request(s) for ELIGIBLE. Do not normalize or repair an unsupported pattern to force eligibility."

addedInput schema / properties / after / examples
```
Added value: +[
+  "mcp://*"
+]
```

addedInput schema / properties / before / description

Added value: +"Previous service-grant pattern, preserved exactly. Examples: * (all services), mcp://* (all MCP services), or mcp://weather (one service). Supported patterns use ASCII text of at most 128 bytes; paths, queries and fragments are outside this domain."

addedInput schema / properties / before / examples
```
Added value: +[
+  "*"
+]
```

addedInput schema / properties / required_name / description

Added value: +"Exact required service name, for example weather, not an individual tool name or a path such as weather/forecast. Supported nonempty names contain ASCII letters, digits, - and _ in nonempty dot-separated labels, at most 128 bytes. Preserve the supplied spelling; Gooo decides domain validity."

addedInput schema / properties / required_name / examples
```
Added value: +[
+  "weather"
+]
```

addedInput schema / properties / required_type / description

Added value: +"Exact required service type, for example mcp or http; not a full URI. The supported domain is ASCII, at most 128 bytes, starting with a letter when nonempty, followed by letters, digits, +, - or .; Gooo decides domain validity."

addedInput schema / properties / required_type / examples
```
Added value: +[
+  "mcp"
+]
```

addedOutput schema / properties / facts / properties / after / description

Added value: +"Proposed replacement service-grant pattern, using the same syntax as before. It must be a supported subset and preserve the supplied required request(s) for ELIGIBLE. Do not normalize or repair an unsupported pattern to force eligibility."

addedOutput schema / properties / facts / properties / after / examples
```
Added value: +[
+  "mcp://*"
+]
```

addedOutput schema / properties / facts / properties / before / description

Added value: +"Previous service-grant pattern, preserved exactly. Examples: * (all services), mcp://* (all MCP services), or mcp://weather (one service). Supported patterns use ASCII text of at most 128 bytes; paths, queries and fragments are outside this domain."

addedOutput schema / properties / facts / properties / before / examples
```
Added value: +[
+  "*"
+]
```

addedOutput schema / properties / facts / properties / required_name / description

Added value: +"Exact required service name, for example weather, not an individual tool name or a path such as weather/forecast. Supported nonempty names contain ASCII letters, digits, - and _ in nonempty dot-separated labels, at most 128 bytes. Preserve the supplied spelling; Gooo decides domain validity."

addedOutput schema / properties / facts / properties / required_name / examples
```
Added value: +[
+  "weather"
+]
```

addedOutput schema / properties / facts / properties / required_type / description

Added value: +"Exact required service type, for example mcp or http; not a full URI. The supported domain is ASCII, at most 128 bytes, starting with a letter when nonempty, followed by letters, digits, +, - or .; Gooo decides domain validity."

addedOutput schema / properties / facts / properties / required_type / examples
```
Added value: +[
+  "mcp"
+]
```

First observedv0.1.0-preview.1Oct 20, 2026

TDQS

A4.2/5.0

Behavior3/5

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

Annotations already declare readOnly, idempotent and closed-world, so safety framing is partly redundant. The description still adds real context beyond that: domain-invalid facts yield INVALID_INPUT, malformed arguments yield a tool error with no decision, and supplied facts are unauthenticated with no grant or API operation applied. Missing only scale or edge-condition detail.

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?

Four tight sentences, front-loaded with the trigger and the assessment rule, then error behavior, then the authentication caveat. Dense but no filler; a slightly lighter touch on the trailing disclaimer would earn a 5.

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?

Output schema exists, so return values need not be explained, and the description still covers the non-obvious outcome cases (INVALID_INPUT vs. tool error). Nothing an agent needs in order to call this correctly is missing.

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 coverage is 100%, so every parameter is already documented including domain constraints and examples. The description adds the relational meaning (after must be a supported subset of before and preserve the required request), but that largely restates the after/required_name schema text. 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 ('Assesses whether after is a supported subset of before') along with the eligibility conditions tying in required_type and required_name. It also names the sibling assess_service_grant_change and the case (ordered request lists) that selects it, so an agent can distinguish the two without opening either 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?

Opens with an explicit trigger ('Use when considering a narrower service grant that must preserve one required service request') and routes the ordered-list case to assess_service_grant_change. Both the when-to-use and the alternative are stated outright.

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

Deploy Server