Gooo policy and MCP change checks
A local stdio MCP server that lets an agent check whether a proposed service-grant narrowing preserves required service requests, without applying any grant or calling any service.
Assess one request (
assess_service_grant, default): givenbefore,after,required_type,required_name, returns the supplied facts, a seven-field decision (ELIGIBLE/REFUSED/INVALID_INPUT) and full compiler/generation/source bindings.Assess an ordered list (
assess_service_grant_change, with--many-required): preserves order and duplicates acrossrequired_requests, returning ordered-column facts, 12 typed decision fields and 30-asset/five-source-hash bindings; domain-invalid input and the 257-request limit are decisions, not tool errors.Compare tool-alias origins (
gooo_compare_alias_origin, with--alias-origin-change): given atarget_aliasand before/after catalogs, reportsORIGIN_CHANGED,UNCHANGED,ADDED,REMOVED,ABSENT,AMBIGUOUSorINVALID_INPUTwith digests.Return complete proofs in both
structuredContentand a JSON text block, with strict input validation (duplicate keys, nulls, wrong types, unpaired surrogates, size/frame limits) surfacing asisError: true.Run offline and unauthenticated: no HTTP port, API key, model call or runtime Go/Gooo install; supplied facts are never authenticated and
execution_authorizedstays false.
Inspect a service-grant change through MCP
This local stdio server lets a coding agent discover and call one tool,
assess_service_grant. It checks whether a supported narrowing preserves one
required service request. The decision is made by the existing Gooo generation;
the Go adapter only handles MCP and exact fact transport.
For example, narrowing * to mcp://* retains mcp://weather. Narrowing the
same grant to http://* removes that request. Both are successful assessments,
with different decisions.
Build and connect
Build from a reviewed checkout with Go 1.27.3:
GOTOOLCHAIN=local GOWORK=off CGO_ENABLED=0 \
go -C examples/service-grant-mcp build -trimpath -o /absolute/private/bin/gooo-service-grant-mcp .The build downloads the pinned public modules through the configured Go proxy and checksum service. The resulting native executable needs no Go or Gooo installation at runtime. Configure your MCP host to launch the absolute executable path over stdio, without arguments. This server opens no HTTP port, needs no API key and performs no model call.
The Python standard-library wire verifier exercises protocol versions
2025-11-25 and 2026-07-28. It checks discovery, tool schemas, repeated calls,
exact native CLI proof equality, strict input errors and protocol-only stdout.
The Go tests also compare concurrent handler calls with those complete native
proofs; the focused workflow runs them with the race detector on Linux and macOS.
Five Python regression checks use actual exited child processes and buffered
pipes to verify that a failed request retains its first error and diagnostics.
Injected cancellation exceptions check propagation after cleanup; they do not
establish operating-system signal behavior.
These observations do not establish that a task was completed inside any
particular agent application.
Related MCP server: Epistemic Warrant Protocol (EWP)
Call the tool
Choose assess_service_grant for one required service request, or start the
server with --many-required and choose assess_service_grant_change for an
ordered list. Discovery includes descriptions and examples for every input
field, including each list item's type and name. These identify a service
such as mcp://weather, rather than an individual tool or a URL path.
Use before for the previous grant and after for the proposed replacement;
preserve supplied text instead of repairing an unsupported identifier.
Supply exactly four JSON strings as the tool arguments object:
{
"before": "*",
"after": "mcp://*",
"required_type": "mcp",
"required_name": "weather"
}The result includes the original facts, a seven-field decision and the full
compiler/generation/source bindings, in both MCP structuredContent and a JSON
text content block. Preserve the complete result.
Result | Meaning |
| This supported subset preserves the supplied required request. |
| The represented change fails the preservation or refinement check. |
| The strings do not meet the Gooo policy's canonical domain. |
MCP | Transport, source-binding or execution failure; no policy decision is returned. |
Duplicate keys, missing or extra fields, null, wrong types and unpaired Unicode surrogates are transport errors. The raw arguments object is limited to 4,096 bytes; a complete inbound stdio frame is separately limited to 64 KiB. These transport limits are distinct from the policy's represented string domain.
The supplied previous grant and required request are not authenticated here. The tool applies no grant, checks no live authority and contacts no service. The conditional application example demonstrates the separate version/writer guards needed by an application that automatically applies a change.
Versions and verification
The runtime is pinned to the public
agentmesh-service-policy module
v0.0.0-20261020182808-7180a4a0f36a. Its Gooo compiler source is
205896a413e5dea92366309c35ae85e542d055f6; this adapter does not upgrade or
run the language engine. MCP transport uses the official Go SDK v1.8.0.
go.sum pins both modules and their dependency graph.
The files under fixtures/ retain actual native CLI inputs and outputs.
fixtures/origin.json records their hashes, actual public module, Go 1.27.3
build identity and platform. Earlier Linux observations are retained as history;
they do not certify these new bytes. The verifier compares whole proof objects, including false/empty fields
and all 89 asset bindings; it does not reconstruct a substitute policy result.
To verify a built command, choose a fresh output directory:
python3 -I -B examples/service-grant-mcp/verify.py \
--binary /absolute/private/bin/gooo-service-grant-mcp \
--out /absolute/private/new-mcp-verificationReport the platform, source version, command, exit status and first diagnostic in the first-run feedback form. Choose Native setup, verification, or replay and use synthetic public facts. Feedback about a real task or a missing capability is more useful than a claim of compatibility with every MCP client or every service-pattern language.
Optional ordered required requests
The default command and assess_service_grant tool use the current 205
profile, seven decision fields and 89 asset bindings. Start the same native
command with --many-required to additionally expose
assess_service_grant_change. Its arguments are one object, for example:
{"before":"*","after":"mcp://*","required_requests":[{"type":"mcp","name":"weather"},{"type":"mcp","name":"calculator"}]}The optional tool preserves request order and duplicates. It returns the complete
ordered-column facts, 12 typed decision fields and the many-request generation's
30 asset and five source-hash bindings. Both policy modules were generated with
compiler 205896a using Go 1.27.3. Domain-invalid requests and the 257-request
policy limit return decisions; malformed JSON returns no partial proof. Supplied
facts are unsigned: this tool authenticates no authority and applies no grant.
The five Gooo source bodies remain repository sources, not embedded module files.
Run the existing default wire check and the optional check separately after
building the transport as above. The optional check reads the exact public
service-grant-many dependency selected by this module:
mcp_binary=/absolute/private/bin/gooo-service-grant-mcp
mkdir -p out
python3 -I -B examples/service-grant-mcp/verify.py \
--binary "$mcp_binary" --out "$PWD/out/mcp-default-wire"
many_module="$(go -C examples/service-grant-mcp list -m -f '{{.Dir}}' \
github.com/kimjooyoon/gooo-go-ports/examples/service-grant-many)"
python3 -I -B examples/service-grant-mcp/verify_many.py \
--binary "$mcp_binary" \
--legacy-verifier "$PWD/examples/service-grant-mcp/verify.py" \
--many-module "$many_module" --out "$PWD/out/mcp-many-wire"Both clients exercise the two documented protocol versions without a model.
The paired MCP input cannot express a mismatch between two column lengths; that
separate public Go API case remains covered in service-grant-many tests.
Optional tool-alias origin comparison
Build this checkout's command and start it with --alias-origin-change to add
the read-only tool gooo_compare_alias_origin. This source profile is not in
the previously released preview16 executable or image. It reuses the public
alias-origin-change module at
v0.0.0-20261024154510-16d1e7864dc8, without invoking Go or Gooo at runtime.
The module's compiler pin is 205896a413e5dea92366309c35ae85e542d055f6 and its
embedded generation document is pinned by SHA-256
b0c87b7865697c4b6433ef54e23defd7267ed8ea4da562cc8e1af24e283e7b06.
The default command still exposes only assess_service_grant;
--many-required still exposes the same two service-grant tools. The alias
option alone exposes those default and alias tools (two total). Both options
together expose all three tools, in either argument order. Duplicate or unknown
options are errors. A host with an enabled_tools allowlist must also include
gooo_compare_alias_origin before the agent can discover it.
Use it when a name chosen by an agent might resolve to a different declared server or original function after an update. Pass one exact arguments object:
{"target_alias":"docs_search","before":[{"server":"docs","original_name":"search","exposed_name":"docs_search"}],"after":[{"server":"issues","original_name":"query","exposed_name":"docs_search"}]}This returns ORIGIN_CHANGED: the supplied alias moved from docs/search to
issues/query. Review that change before relying on the previous tool choice.
UNCHANGED means the supplied origin pair is the same. ADDED, REMOVED and
ABSENT describe presence in the two supplied lists. AMBIGUOUS identifies a
duplicate exposed name anywhere in either catalog, even an unrelated alias;
repair those indexed rows and compare fresh facts. Empty domain text returns
INVALID_INPUT. See the complete recovery guide
for the next action for every state.
The adapter passes the received arguments bytes directly to CompareJSON.
It returns the complete facts, facts_sha256, input_sha256, nine-field
decision and bindings in both structuredContent and JSON text. The input
digest identifies the exact arguments object received through MCP, including
its whitespace; it does not identify the whole JSON-RPC request. Original row
positions are zero-based. Text is opaque: preserve spelling, order and Unicode
without trimming, case folding or normalization. The executable contains exact
snapshots of the pinned module's input
and output schemas for discovery;
wire checks compare these with the public module rather than defining a second
schema contract.
Each catalog allows at most 256 rows, each text at most 1,024 UTF-8 bytes, and
the raw arguments object at most 1 MiB. The alias profile allows another 64 KiB
for inbound JSON-RPC framing; the default 64 KiB and existing many-request
frame limits are unchanged. Invalid JSON, duplicate keys, null arrays, invalid
Unicode or transport bounds return isError: true with the public JSON
diagnostic in text and no partial report. These are separate from the seven
represented decision states.
The serialized report retains its separate 4 MiB limit. A complete outbound
JSON-RPC frame, including structured content, the escaped text copy, metadata,
request IDs, any batch framing and the final newline, is limited to
16 MiB + 64 KiB only in the alias profile. The larger bound accounts for two
copies of a report and additional JSON escaping and framing; a report size
alone is not a wire size. An oversized frame replaces its alias reports with
isError: true diagnostics whose state/stage/code are
INVALID_TRANSPORT / encode_result / MCP_WIRE_LIMIT_EXCEEDED, without writing
partial reports. Other tools' results in a mixed frame are preserved; an output
that cannot be reduced within the bound fails the connection without writing
that frame. This output-only diagnostic extends the module's CLI diagnostics.
These comparisons use supplied snapshots. They do not authenticate catalog
completeness, live server identity, SDK routing or current authority. Every
represented result retains execution_authorized: false. No named tool,
service or model is called.
The separate verify_alias.py wire check uses a built comparison CLI from the
same pinned public module as its complete-report reference, on protocols
2025-11-25 and 2026-07-28. Its default --scope full includes large accepted
responses and the independent 4 MiB report refusal. --scope bundle-small
checks the fixed small cases and all four discovery modes for an extracted
binary; it does not repeat or claim the large-response observations. Both
scopes retain command identities, exact streams and child-process closure.
These are finite internal protocol checks, not a completed task in an external
agent application or a published release.
After building the MCP command above, build its reference CLI from the same pinned dependency in the MCP module context, then use a fresh evidence directory:
mcp_binary=/absolute/private/bin/gooo-service-grant-mcp
alias_cli=/absolute/private/bin/alias-compare
GOTOOLCHAIN=local GOWORK=off CGO_ENABLED=0 \
go -C examples/service-grant-mcp build -trimpath -o "$alias_cli" \
github.com/kimjooyoon/gooo-go-ports/examples/alias-origin-change/cmd/compare
alias_module="$(go -C examples/service-grant-mcp list -m -f '{{.Dir}}' \
github.com/kimjooyoon/gooo-go-ports/examples/alias-origin-change)"
python3 -I -B examples/service-grant-mcp/verify_alias.py \
--binary "$mcp_binary" --alias-cli "$alias_cli" \
--alias-module "$alias_module" --go "$(go env GOROOT)/bin/go" \
--out /absolute/private/new-alias-wire --scope fullThe Go executable in this verification command only inspects the two binaries'
build identities. The actual CLI and MCP calls run with empty PATH and absent
GOROOT; no model or external service is used.
Compare saved tool definitions
This source tree adds --definition-snapshot, independently or alongside the
other two optional flags. The fixed preview.16 installation does not include
this option. Build this checkout with Go 1.27.3 before configuring its absolute
binary path in your MCP client:
go -C examples/service-grant-mcp build -trimpath -o /absolute/path/gooo-service-grant-mcp .Use args: ["--definition-snapshot"] to discover
gooo_compare_saved_tool_definitions. Its arguments are an object with
target_name, before.pages and after.pages; each page contains the exact
request_json and response_json strings from a saved tools/list exchange.
An example arguments object is included. Keep
page order and continuation cursors. Empty arrays represent missing saved pages;
do not synthesize successful empty lists to fill a gap.
The tool returns the complete generated-Gooo comparison as both structured
content and text: projection, original input, decision and source bindings.
Read decision.state together with both page coverage fields. A selected row
can be compared even when other pages are missing. Absence from an incomplete
page set remains UNASSESSED; duplicate names remain ambiguous. INVALID_INPUT
is a domain result, whereas malformed arguments return a tool error without a
decision. The transport preserves the raw arguments it receives; JSON-RPC
framing whitespace is separate from the saved page strings.
This compares supplied observations without fetching a live catalog, inventing
host aliases or invoking a tool. Origin and authorization remain NOT_ASSESSED,
behavior equivalence and execution authorization remain false. A host may use
the result to choose another observation or comparison step under its own
policy, without requiring a person to approve each comparison.
The source uses the fixed public comparison module
v0.0.0-20261027155614-e4d44fd856ee, generated by compiler 205896a.
The output's decision shape is rendered from the stable Gooo record ID, using
the existing package-interface command in an explicitly separate 1afb98b
declaration inspection. Schema provenance
retains the source, workspace, field IDs and renderer hashes. This inspection
does not replace the kernel compiler pin or claim another program execution;
UTF-8 byte facets are not converted into JSON Schema character limits.
Runtime needs no Gooo compiler, Go toolchain, credentials or model. The optional
profile admits at most 1 MiB of arguments plus separate JSON-RPC framing; the
public library bounds a report at 4 MiB. A final 16 MiB plus 64 KiB wire bound
covers both result representations and batch framing, returning a bounded tool
error instead of a partial oversized report.
Available Tools
4 toolsassess_service_grantCheck a service-grant narrowingARead-onlyIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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 |
|---|---|---|
| facts | Yes | |
| bindings | Yes | |
| decision | Yes |
TDQS
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.
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.
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.
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.
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.
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.
assess_service_grant_changePreserve an ordered service-request listARead-onlyIdempotent
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.
| Name | Required | Description | Default |
|---|---|---|---|
| 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_requests | Yes | 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. |
Output Schema
| Name | Required | Description |
|---|---|---|
| facts | Yes | |
| bindings | Yes | |
| decision | Yes |
TDQS
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.
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.
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.
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.
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.
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.
gooo_compare_alias_originCompare a tool alias's declared originARead-onlyIdempotent
Use before a tool-catalog update when an agent-selected exposed name may point to a different server or original function. Supply one target_alias and exact before/after rows with server, original_name and exposed_name. Returns UNCHANGED, ORIGIN_CHANGED, ADDED, REMOVED, ABSENT, AMBIGUOUS or INVALID_INPUT; inspect the original zero-based indexes. Any duplicate exposed name anywhere in either catalog is AMBIGUOUS. Empty domain text returns INVALID_INPUT; malformed JSON or transport limits return a tool error without a report. Preserve supplied spelling and order. These are supplied snapshots, not proof of live server identity, SDK routing, completeness or authority. No tool is invoked and execution_authorized is always false.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | ||
| target_alias | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| facts | Yes | |
| bindings | Yes | |
| decision | Yes | |
| facts_sha256 | Yes | |
| input_sha256 | No |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent/closed-world annotations by disclosing that no tool is invoked, execution_authorized is always false, malformed JSON or transport limits produce a tool error with no report, and that the result is not proof of live server identity, SDK routing, completeness or authority. These are exactly the caveats an agent needs to avoid over-trusting the comparison.
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?
Front-loaded with the usage trigger, then the inputs, then the status vocabulary, then the error and trust caveats — a logical progression with no filler. Some sentences are dense and comma-spliced, which costs a little readability.
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?
Enumerates all seven outcome statuses (UNCHANGED through INVALID_INPUT), explains the AMBIGUOUS rule for duplicate exposed names in either catalog, and points to the original zero-based indexes for inspection. With an output schema present, this is more than sufficient for correct invocation and interpretation.
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?
With 0% schema description coverage the description must compensate, and it does: it specifies one target_alias plus exact before/after rows containing server, original_name and exposed_name, and that supplied spelling and order are preserved. The phrase 'empty domain text returns INVALID_INPUT' is slightly unclear about which field counts as domain text, leaving a small gap.
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?
States a specific verb and resource — comparing a tool alias's declared origin across supplied before/after catalogs — and the title/description pairing makes clear this is a diff over two snapshots rather than a live lookup. It is distinguishable from the sibling gooo_compare_saved_tool_definitions by operating on alias origin rows rather than saved definitions.
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?
The first sentence gives an explicit trigger: use before a tool-catalog update when an agent-selected exposed name may point to a different server or original function. That is a clear when-to-use condition, though no sibling alternative is named for the non-update case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
gooo_compare_saved_tool_definitionsARead-onlyIdempotent
Compare one original MCP tool definition in saved before/after tools/list request/response pages with Gooo. Use during an upgrade or reconnect review when no host alias history exists. Returns definition and annotation relations, coverage, source rows and the complete report. Keep pages in observed order and missing pages missing. No live collection, tool execution, behavior equivalence or authorization is established. Malformed input is a tool error; UNASSESSED is a successful comparison with insufficient observations.
| Name | Required | Description | Default |
|---|---|---|---|
| after | Yes | ||
| before | Yes | ||
| target_name | Yes | Original tool name in the saved server descriptors, not a host alias. The decoder enforces at most 1024 UTF-8 bytes. Empty names remain domain input for Gooo. |
Output Schema
| Name | Required | Description |
|---|---|---|
| inputs | Yes | |
| schema | Yes | |
| bindings | Yes | |
| decision | Yes | |
| projection | Yes |
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only/idempotent annotations, the description discloses important limits: no live collection, no tool execution, no behavior-equivalence claim, and no authorization claim. It also distinguishes malformed-input errors from successful UNASSESSED comparisons with insufficient observations.
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?
The description is front-loaded and compact: purpose, usage condition, return shape, input preservation rules, limitations, and error semantics all appear in a few dense sentences with no filler.
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?
The tool is complex, with nested before/after page objects and an output schema, and the description covers the key context an agent needs: when to use it, what is compared, what is returned, what is not established, and how errors versus UNASSESSED results behave.
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?
The schema already documents the nested request_json, response_json, and pages fields in detail, and the description mostly restates the requirement to preserve page order and missing pages. It adds useful before/after context, but does not fully compensate for the low top-level schema-description coverage.
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?
The description gives a specific verb and resource: comparing one original MCP tool definition across saved before/after tools/list pages. It also distinguishes the tool from the alias-history sibling by saying it is for when no host alias history exists.
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?
It clearly states the operational scenario: use during an upgrade or reconnect review when no host alias history exists. The exclusion is present, but it does not explicitly name gooo_compare_alias_origin as the alternative when alias history does exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
2 tool updates
v0.1.0-preview.4- Added
gooo_compare_alias_origin - Added
gooo_compare_saved_tool_definitions
2 tool updates
v0.1.0-preview.3- Changed
assess_service_grant16 fields changed- added
Input schema / properties / after / descriptionAdded 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." - added
Input schema / properties / after / examplesAdded value: +[ + "mcp://*" +] - added
Input schema / properties / before / descriptionAdded 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." - added
Input schema / properties / before / examplesAdded value: +[ + "*" +] - added
Input schema / properties / required_name / descriptionAdded 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." - added
Input schema / properties / required_name / examplesAdded value: +[ + "weather" +] - added
Input schema / properties / required_type / descriptionAdded 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." - added
Input schema / properties / required_type / examplesAdded value: +[ + "mcp" +] - added
Output schema / properties / facts / properties / after / descriptionAdded 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." - added
Output schema / properties / facts / properties / after / examplesAdded value: +[ + "mcp://*" +] - added
Output schema / properties / facts / properties / before / descriptionAdded 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." - added
Output schema / properties / facts / properties / before / examplesAdded value: +[ + "*" +] - added
Output schema / properties / facts / properties / required_name / descriptionAdded 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." - added
Output schema / properties / facts / properties / required_name / examplesAdded value: +[ + "weather" +] - added
Output schema / properties / facts / properties / required_type / descriptionAdded 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." - added
Output schema / properties / facts / properties / required_type / examplesAdded value: +[ + "mcp" +]
- Changed
assess_service_grant_change9 fields changed- added
Input schema / properties / after / descriptionAdded 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." - added
Input schema / properties / after / examplesAdded value: +[ + "mcp://*" +] - added
Input schema / properties / before / descriptionAdded 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." - added
Input schema / properties / before / examplesAdded value: +[ + "*" +] - added
Input schema / properties / required_requests / descriptionAdded 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." - added
Input schema / properties / required_requests / items / properties / name / descriptionAdded 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." - added
Input schema / properties / required_requests / items / properties / name / examplesAdded value: +[ + "weather" +] - added
Input schema / properties / required_requests / items / properties / type / descriptionAdded 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." - added
Input schema / properties / required_requests / items / properties / type / examplesAdded value: +[ + "mcp" +]
2 tool updates
v0.1.0-preview.1- First observed
assess_service_grant - First observed
assess_service_grant_change
TDQS
Scored across 4 tools
Each tool has a distinct purpose: alias-origin comparison, saved tool-definition comparison, single-request grant assessment, and ordered-list grant assessment. The descriptions explicitly clarify when to use each variant and cross-reference the alternative for closely related grant tools.
All names use readable snake_case with a verb-first pattern, such as compare_* and assess_*. The only inconsistency is that the two comparison tools carry a gooo_ prefix while the grant-assessment tools do not.
Four tools is well-scoped for a specialized policy/MCP change-checking server. Each tool covers a clear assessment case without redundant variants beyond the necessary single-vs-list distinction.
The surface covers the main advertised checks: alias-origin comparison, saved tool-definition comparison, and service-grant narrowing for both single and ordered requests. It is intentionally assessment-only and snapshot-based, which leaves minor gaps around live validation but is consistent with the stated scope.
Maintenance
Related MCP Connectors
Sounding checks proposed decisions and returns structured proceed, revise, or pause assessments.
Advisory policy preflight for AI-agent spend requests; never executes payments or accesses wallets.
Check proposed actions against existing policies. Never executes actions. Customer key required.
Evidence-bound second-opinion audit of an agent conclusion against caller-supplied evidence.
Related MCP Servers
- AlicenseAqualityDmaintenanceDeterministically evaluates whether a proposed agent spend action matches a supplied policy, returning ELIGIBLE, DENY, or STEP_UP with stable reason codes. Provides local policy evidence only, not payment authorization.128 npmMIT
- AlicenseAqualityAmaintenanceHelps AI agents decide what they are justified in believing from the evidence they have. EWP separates stored memory from verified knowledge, preserves conflicts and source lineage, and produces a deterministic warrant result that MCP clients can use consistently across different memory systems.81MIT
- AlicenseAqualityBmaintenanceEnables coding agents to submit their original request, proposed plan items, and observed repository conventions for per-item necessity scoring before making edits. It returns advisory keep, simplify, or review recommendations with reasons and evidence, without blocking or modifying the plan.13 npmMIT

aethis-mcpofficial
AlicenseAqualityAmaintenanceEnables clients to run deterministic eligibility and decision evaluations from compiled legislation, policy, contracts, and regulation, inspect schemas and traces, route next questions, and discover rulesets, with optional private-beta authoring tools for rule generation, testing, refining, and publishing.3560 npm1MIT