Skip to main content
Glama
kimjooyoon

Gooo policy and MCP change checks

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

ELIGIBLE

This supported subset preserves the supplied required request.

REFUSED

The represented change fails the preservation or refinement check.

INVALID_INPUT

The strings do not meet the Gooo policy's canonical domain.

MCP isError: true

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-verification

Report 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 full

The 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 tools
assess_service_grantCheck a service-grant narrowingA
Read-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.

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_nameYesExact 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_typeYesExact 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

NameRequiredDescription
factsYes
bindingsYes
decisionYes

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.

assess_service_grant_changePreserve an ordered service-request listA
Read-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.

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

NameRequiredDescription
factsYes
bindingsYes
decisionYes

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.

gooo_compare_alias_originCompare a tool alias's declared originA
Read-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.

NameRequiredDescriptionDefault
afterYes
beforeYes
target_aliasYes

Output Schema

NameRequiredDescription
factsYes
bindingsYes
decisionYes
facts_sha256Yes
input_sha256No

TDQS

A4.6/5.0
Behavior5/5

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.

Conciseness4/5

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.

Completeness5/5

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.

Parameters4/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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_definitionsA
Read-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.

NameRequiredDescriptionDefault
afterYes
beforeYes
target_nameYesOriginal 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

NameRequiredDescription
inputsYes
schemaYes
bindingsYes
decisionYes
projectionYes

TDQS

A4.5/5.0
Behavior5/5

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.

Conciseness5/5

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.

Completeness5/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines4/5

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.

  1. 2 tool updatesv0.1.0-preview.4
    • Addedgooo_compare_alias_origin
    • Addedgooo_compare_saved_tool_definitions
  2. 2 tool updatesv0.1.0-preview.3
    • Changedassess_service_grant16 fields changed
      • 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"
        +]
    • Changedassess_service_grant_change9 fields changed
      • 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"
        +]
  3. 2 tool updatesv0.1.0-preview.1
    • First observedassess_service_grant
    • First observedassess_service_grant_change

TDQS

A4.4/5.0

Scored across 4 tools

Disambiguation5/5

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.

Naming Consistency4/5

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.

Tool Count5/5

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.

Completeness4/5

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

ActivityMaintained
ResponsivenessResponsive

Related MCP Connectors

Related MCP Servers

  • A
    license
    A
    quality
    D
    maintenance
    Deterministically 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.
    1
    28 npm
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Helps 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.
    8
    1
    MIT
  • A
    license
    A
    quality
    B
    maintenance
    Enables 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.
    1
    3 npm
    MIT
  • A
    license
    A
    quality
    A
    maintenance
    Enables 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.
    35
    60 npm
    1
    MIT