Skip to main content
Glama
Sign In
Gooo policy and MCP change checks

Gooo policy and MCP change checks

by kimjooyoon
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

Preserve an ordered service-request list

assess_service_grant_change
Read-onlyIdempotent

Assess a proposed service-grant narrowing to confirm it preserves an ordered list of required service requests, including duplicates, before applying any grant changes.

Instructions

Use when one proposed service-grant narrowing must preserve an ordered list of required service requests, including duplicates. For one request with flat required_type/required_name fields, use assess_service_grant. Domain-invalid facts and request-limit excess return INVALID_INPUT decisions; malformed arguments return a tool error with no decision. Supplied facts are not authenticated; no grant or service operation is applied.

Input Schema

NameRequiredDescriptionDefault
afterYesProposed 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.
beforeYesPrevious 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_requestsYesRequired service requests to preserve in their original order, including duplicates. Each item has exact type and name fields. Do not sort or deduplicate. Empty lists and lists above the supported 256-request policy limit return Gooo decisions; malformed JSON or an arguments object exceeding 1 MiB is a tool error.

Output Schema

NameRequiredDescriptionDefault
factsYes
bindingsYes
decisionYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv0.1.0-preview.3
    • 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_requests / description
      Added value: +"Required service requests to preserve in their original order, including duplicates. Each item has exact type and name fields. Do not sort or deduplicate. Empty lists and lists above the supported 256-request policy limit return Gooo decisions; malformed JSON or an arguments object exceeding 1 MiB is a tool error."
    • addedInput schema / properties / required_requests / items / properties / 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_requests / items / properties / name / examples
      Added value: +[
+  "weather"
+]
    • addedInput schema / properties / required_requests / items / properties / 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_requests / items / properties / type / examples
      Added value: +[
+  "mcp"
+]
  2. First observedv0.1.0-preview.1

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the readOnly/idempotent/openWorld annotations, the description discloses outcome classes (INVALID_INPUT decisions for domain-invalid facts and request-limit excess, tool error for malformed arguments) and a security caveat (facts are unauthenticated, no grant or service operation applied). It does not describe the decision payload itself, but the output schema covers that.

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 dense sentences with the usage condition front-loaded and the sibling routing second; nothing is filler. It is tightly packed with clause-level detail, which slightly taxes first-pass reading but earns its space.

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 explained, and the description covers use context, sibling routing, error/decision behavior and side-effect profile. Nothing an agent needs to invoke 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 description coverage is 100%, so the schema already documents syntax, limits and ordering semantics for before/after/required_requests. The description adds only the emphasis on ordering and duplicates, which the schema's required_requests description already states, so baseline 3 applies.

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 — evaluating a proposed service-grant narrowing that must preserve an ordered list of required service requests — and immediately distinguishes itself from the flat-field sibling assess_service_grant. An agent can route between the two without opening the 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 'Use when' condition and names the alternative plus the exact condition that selects it ('one request with flat required_type/required_name fields'). It also states what happens in edge cases (INVALID_INPUT vs tool error), leaving nothing to inference.

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

Deploy Server

Other Tools