Skip to main content
Glama
ahines99

portco-mcp

by ahines99
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

submit_mapping_review

Record reviewer decisions for pending mapping or test-failure packets—approve, reject, or override—using the exact subject hash and gate from pending reviews; stale packets are rejected.

Instructions

Record a reviewer's decisions for an observed mapping or test-failure packet.

    Decisions: approve | reject | approve_with_override (override keys: canonical_field, transform,
    pii_handling). Supply the exact subject_hash and gate returned by list_pending_reviews.
    Stale packets are rejected. Certification must use certify_run. Reviewer principals only.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
gateYes
run_idYes
commentNo
decisionsYes
subject_hashYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
gateYes
run_idYes
reviewerYes
decisionsYes
approval_idYes
next_actionYes
subject_hashYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.1
    • addedInput schema / properties / gate
      Added value: +{
+  "enum": [
+    "mapping_review",
+    "test_failures"
+  ],
+  "title": "Gate",
+  "type": "string"
+}
    • addedInput schema / properties / subject_hash
      Added value: +{
+  "title": "Subject Hash",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "run_id",
-  "decisions"
-]New value: +[
+  "run_id",
+  "subject_hash",
+  "gate",
+  "decisions"
+]
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, non-idempotent, closed-world), the description adds real behavioral context: stale packets are rejected and only reviewer principals may call it. The override sub-keys for approve_with_override are also disclosed. It stops short of describing consequences of a rejected/partial submission or how decisions interact within one packet.

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?

Purpose is front-loaded, followed by the decision vocabulary, provenance requirement and constraints in a tight block. No filler sentences; every clause carries operational information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/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 described, and the description covers the mutation's auth, staleness and alternative-tool context. Minor gaps remain around run_id/comment semantics and what happens when only some decisions in a packet are acted on.

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 0%, so the description must carry the load. It does document the decision enum values, the override keys (canonical_field, transform, pii_handling), and the provenance requirement for subject_hash and gate, but leaves run_id and the top-level comment unexplained and never states the gate enum values.

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+resource: recording a reviewer's decisions against an observed mapping or test-failure packet, and names the two gates it applies to. It also distinguishes itself from certify_run, which handles certification, so the agent can route correctly 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?

Explicitly says to supply the exact subject_hash and gate returned by list_pending_reviews (naming the prerequisite sibling), warns that stale packets are rejected, restricts callers to reviewer principals, and redirects certification to certify_run. When-to-use, prerequisites and the key alternative are all stated.

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