GovernancePlatform MCP Server

validate

Validate structured data against a Blueprint's rules. Returns PASS, FAIL, or REVIEW. The platform checks mathematical accuracy (do the numbers add up?), structural consistency (do the fields satisfy all constraints?), and semantic plausibility (do the values make sense in context?). Every result includes a determinism hash — the same input with the same Blueprint always produces the same result. Auditable, replayable, legally defensible. A Blueprint is required for meaningful validation. Without one, use create_blueprint or load_rule_pack to define your governance rules first. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: The data to validate (key-value pairs) blueprint: Name of the Blueprint to validate against. Use list_blueprints to see options.

validate_repair

Validate structured data and automatically compute repairs if it fails. Single call that combines validate + repair. Different from validate: validate returns only the verdict; if the data fails, you'd then call repair separately. validate_repair returns the verdict AND the repaired payload in one call. Different from repair: repair always returns repair suggestions regardless of whether the input was valid; validate_repair only computes repairs when validation actually fails. If PASS: returns the validated data with determinism hash. If FAIL: returns the failure details AND a repaired payload with field-by-field corrections and confidence scores. The agent can inspect the repairs and resubmit the corrected data. If REVIEW: returns the flagged data with review reasoning. This is the recommended starting point for most agent integrations. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: The data to validate (key-value pairs) blueprint: Name of the Blueprint to validate against. Use list_blueprints to see options.

create_blueprint

Create a Blueprint — a governance contract that defines validation rules. A Blueprint tells the platform what "correct" means for your data: which fields exist, what math must hold between them, and what value ranges are acceptable. Without a Blueprint, the platform has nothing to validate against. If you don't know what rules to define, use load_rule_pack to start from a prebuilt template, or use discover_patterns to find rules from your data. Use the blueprint_guide prompt for the complete reference of all available rule types, constraint types, and configuration options. Args: api_key: GeodesicAI API key (starts with gai_) customer_name: Organization or project name (used for folder naming) workflow_name: Unique identifier for this Blueprint (used as the 'blueprint' parameter in validate) mode: "observe" (platform checks agent's work) or "enforce" (platform computes derived fields) extracted_fields: Fields the agent extracts from source data (e.g. ["vendor", "qty", "unit_cost"]) derived_fields: Fields computed from other fields (e.g. ["subtotal", "total"]) derivation_rules: Math rules defining field relationships. Available types: "add" (target = a + b), "subtract" (target = a - b), "multiply" (target = a × b), "divide" (target = a ÷ b), "round" (round field to N places), "copy" (copy source to target), "items_multiply" (per-item a × b in a list), "items_sum" (sum a field across list items). Each rule requires "type" and the relevant fields. See blueprint_guide prompt for full schema. formal_constraints: Value bounds and ratio constraints. Available types: "magnitude_anchor" (field within min/max range, requires "field", "min", "max"), "relative_anchor" (ratio a/b within tolerance, requires "a", "b", "expected_ratio", "tolerance"), "max_action_threshold" (trigger action if field exceeds threshold, requires "field", "threshold", "action"). See blueprint_guide prompt for full schema. semantic_checks: Domain-specific validation checks require_math: Validate mathematical relationships (default true) require_consistency: Check internal consistency (default true) require_coherence: Check structural coherence (default true) require_provenance: Require agents to report extraction source locations require_high_assurance: Strictest validation — feasibility, spectral, and global consistency required enable_anomaly_detection: Geometric fingerprinting to detect structural outliers enable_drift_tracking: Monitor pattern stability across batches

list_blueprints

List Blueprints owned by the calling account. Returns each Blueprint's name, workflow identifier, mode, and field/rule/constraint counts. Use the workflow_name as the 'blueprint' parameter when calling validate. Blueprint modes — important for agents that summarize results: - "observe" (Observation mode): the platform validates data against the Blueprint's rules and returns PASS, FAIL, or REVIEW with repair suggestions. Validation is detection-only; the caller decides what to do with the result. - "enforce" (Execution mode): the platform performs the same validation AND authorizes downstream side effects. Side effects are blocked if validation fails. In this mode, rules that compute derived values (like totals) publish the platform's computed result as authoritative, so downstream consumers see the canonical value rather than the agent's. Both modes run the same rule checks. The difference is what happens after validation, not during it. Scope: only Blueprints created by the calling account are returned. Use validate / repair / etc. with the workflow_name to operate on them. Args: api_key: GeodesicAI API key (starts with gai_)

repair

Compute the nearest valid point on the constraint manifold. Given structured data with errors, missing values, or inconsistencies, returns field-by-field repair suggestions with geometric confidence scores. Uses algebraic projection for linear constraints and iterative geodesic projection for nonlinear constraints. Can accept rules directly or load them from a Blueprint. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: The data to repair (key-value pairs) derivation_rules: Math rules (optional if blueprint is provided) formal_constraints: Constraints (optional if blueprint is provided) blueprint: Load rules from this Blueprint instead of specifying them directly

check_feasibility

Check whether a set of constraints can be simultaneously satisfied. Uses the twist-compression operator to detect structural obstructions — fundamental conflicts in the constraint system that cannot be resolved by adjusting any single field. Returns obstruction type, magnitude, and the specific constraint interactions causing the conflict. Fast pre-check before running full validation. Args: api_key: GeodesicAI API key (starts with gai_) constraints: List of derivation rules and formal constraints to check field_values: Current field values (numeric key-value pairs)

forecast

Deterministic forward reasoning — show what valid states are reachable. Given the current data state, generates candidate next states by applying Blueprint rules, then ranks them by structural quality (lowest drift, highest confidence, shortest path, or lowest risk). Args: api_key: GeodesicAI API key (starts with gai_) structured_data: Current data state blueprint: Blueprint to use for rules and constraints max_depth: How many steps ahead to forecast (1-10) max_branches: Maximum branches per step (1-10) rank_by: Ranking criterion — "drift" (most stable), "confidence" (highest geometric confidence), "shortest" (fewest changes), "risk" (lowest risk)

discover_patterns

Feed a batch of structured data to discover patterns deterministically. No Blueprint required — discovers rules from the data itself. Analyzes the batch using motif discovery, structural routing, and geometric fingerprinting. Returns candidate validation rules with confidence scores, structural type classifications, and anomaly counts. Source data is never stored — only statistical summaries persist. Discovered rules can be promoted into Blueprints using approve_rule. Args: api_key: GeodesicAI API key (starts with gai_) documents: List of structured data objects to analyze blueprint: Namespace for this discovery session

repair_path

Find the shortest path from an invalid state to a valid one. Given data that fails validation, computes a sequence of minimal field changes that would bring the data into compliance with the Blueprint's rules and constraints. Returns the path as an ordered list of intermediate states. Different from repair: repair returns the single nearest valid point on the constraint manifold (a one-shot projection). repair_path returns the trajectory between invalid and valid states — useful when you want to see what's changing step by step, or when there are multiple ways to repair the data and you want to evaluate alternatives. Use repair when you just need the fix; use repair_path when you need to explain or audit the fix. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: Current (invalid) data state blueprint: Blueprint defining the valid constraint space. Caller must own the Blueprint. max_depth: Maximum repair steps to search (1-10). Higher values find paths through more complex repairs but take longer. rank_by: Ranking criterion for selecting among valid paths. One of: "shortest" — fewest changes "drift" — most stable trajectory "confidence" — highest geometric confidence "risk" — lowest risk Returns: path: ordered list of intermediate states, each with field values and structural quality metrics path_length: number of steps in the returned path terminal_state: the final valid state at the end of the path rank_score: score of the chosen path under rank_by alternatives: summary of paths considered but not chosen

counterfactual

Compare outcomes under different rule sets. Given the same data, runs trajectory analysis under two different sets of rules/constraints and shows how the valid state space differs. Useful for what-if analysis: "what happens if I change this rule?" Args: api_key: GeodesicAI API key (starts with gai_) structured_data: Data to analyze blueprint: Primary Blueprint (rule set A) rules_b: Alternative derivation rules (rule set B) constraints_b: Alternative constraints (rule set B)

analyze_anomaly

Deep anomaly analysis with geometric proof. No Blueprint required. Explains WHY data is anomalous using three independent methods: 1. Structural fingerprinting — distance from the learned manifold 2. Cluster analysis — deviation from structural type centroids 3. Twist-compression obstruction — fundamental constraint conflicts Returns a human-readable geometric proof of anomaly, not just a flag. Args: structured_data: The data to analyze for anomalies

create_chain

Create a multi-agent sequential execution chain. Defines a pipeline where multiple agents process data in sequence. Each stage is validated against the Blueprint before the next stage can proceed. Repair suggestions propagate forward through the chain. Different from submit_chain_stage: create_chain defines the pipeline (stages, agent names, TTL); submit_chain_stage executes one stage of an already-created chain. Different from handoff_audit: handoff_audit verifies a transition between stages after they have been submitted. The Blueprint must already exist (use create_blueprint or load_rule_pack first). Each stage in the chain validates against the same Blueprint. Sibling tools: create_chain (define the pipeline), submit_chain_stage (advance through it), handoff_audit (verify between stages). Args: api_key: GeodesicAI API key (starts with gai_) blueprint: workflow_name of the Blueprint governing all stages stages: List of stage definitions, e.g. [{"stage_name": "extract", "agent_name": "PDF Scanner"}, {"stage_name": "validate", "agent_name": "QA Agent"}] Minimum 2 stages required. ttl: Chain timeout in seconds. After this many seconds without progress, the chain expires and submitted stages cannot be advanced. Default: 3600 (1 hour). Returns: chain_id: unique identifier for the chain (use this with submit_chain_stage and handoff_audit) status: initial chain status (typically "active") stages: list of stage records with stage_name, agent_name, and per-stage status next_stage: name of the first stage to submit ttl_seconds: echoed back for caller reference

submit_chain_stage

Submit data for a chain stage. The platform validates the data using the chain's Blueprint, then advances the chain if validation passes. The response includes the next stage info and any accumulated repair suggestions from prior stages. Sibling tools: create_chain (define the pipeline), submit_chain_stage (advance through it), handoff_audit (verify between stages). Args: api_key: GeodesicAI API key (starts with gai_) chain_id: Chain identifier from create_chain stage: Stage name to submit for structured_data: Data for this stage

handoff_audit

Audit a handoff between two chain stages. Returns a context capsule with verified facts from the prior stage and checks structural compatibility of proposed data for the next stage. Use this between chain stages to ensure Agent B receives only verified data from Agent A, and that nothing was mutated in transit. Sibling tools: create_chain (define the pipeline), submit_chain_stage (advance through it), handoff_audit (verify between stages). The context capsule contains: - Verified fields and their values from the prior stage - Determinism hash proving the prior stage's results - Blueprint constraints the next stage must satisfy - Compatibility verdict if proposed_data is provided Args: api_key: GeodesicAI API key (starts with gai_) chain_id: Chain identifier from create_chain from_stage: Stage name that completed (Agent A) to_stage: Stage name about to start (Agent B) proposed_data: Optional data Agent B intends to submit — checked for compatibility

approve_rule

Promote a discovered rule into Blueprint-compatible format. After running discover_patterns, use this to approve high-confidence rules for inclusion in a Blueprint. Args: api_key: GeodesicAI API key (starts with gai_) rule_id: ID of the discovered rule (from discover_patterns results) blueprint: Discovery session namespace

reject_rule

Reject a discovered candidate rule so it will not be promoted into a Blueprint. Use after running discover_patterns when reviewing the candidate rules it produced. Pair with approve_rule: approve high-confidence rules you want enforced, reject the rest. Rejected rules are marked in the discovery session and will not appear in subsequent approval calls or be promotable into Blueprints. The action is recorded against the discovery session namespace; it does not affect any existing Blueprint. Use this when: - A discovered rule is mathematically valid but business-irrelevant - The rule has low confidence and you don't want it surfacing again - You want to clean up the candidate list before promoting approvals Args: api_key: GeodesicAI API key (starts with gai_) rule_id: ID of the discovered rule (from discover_patterns results) blueprint: Discovery session namespace (must match the one used for discover_patterns) Returns: status: "rejected" on success rule_id: The rejected rule's ID blueprint: The discovery session namespace

structural_types

Get auto-discovered structural type classifications from a discovery session. After running discover_patterns, returns the structural categories the platform identified in the data — without being told what categories exist. Each category includes document count, distinguishing fields, and domain hints inferred from the data shape. This is a read-only retrieval. If discover_patterns has not been run against the given blueprint namespace (or the session has expired), returns an empty type list with status="no_session". Use after discover_patterns when you want to understand how the platform grouped your data before deciding which patterns to promote via approve_rule. Args: api_key: GeodesicAI API key (starts with gai_) blueprint: Discovery session namespace (must match the namespace used in discover_patterns) Returns: status: "ok" or "no_session" structural_types: list of {type_id, document_count, distinguishing_fields, domain_hint} total_documents: total document count across all types

decompose_failure

Hodge-style decomposition of validation failures. Splits the error between original and corrected values into three orthogonal components: - Exact: direct rule violations (a field breaks a specific math rule) - Co-exact: constraint boundary violations (a field is at the edge of valid range) - Harmonic: systemic structural errors (the overall data shape is wrong) Different from analyze_anomaly: analyze_anomaly explains why a single payload is anomalous given the platform's structural fingerprints. decompose_failure compares two known states (an original and its correction) and tells you which kind of failure accounts for the difference. Use decompose_failure when you have a known-correct version to diff against; use analyze_anomaly when you only have the suspicious payload. Use this after a validation failure to understand the structural nature of the error, not just which fields differ. Args: api_key: GeodesicAI API key (starts with gai_) original_values: The original field values (numeric key-value pairs) corrected_values: The corrected/expected field values derivation_rules: Math rules. Optional if blueprint provided. formal_constraints: Constraints. Optional if blueprint provided. blueprint: Load rules from this Blueprint instead of passing them inline. Caller must own the Blueprint. Returns: primary_cause: one of "exact" / "co_exact" / "harmonic" exact: details of direct rule violations co_exact: details of constraint boundary violations harmonic: details of systemic structural errors contributing_fields: map of field_name → contribution magnitude total_error_magnitude: scalar L2 norm of the full error

geometric_confidence

Compute a composite geometric confidence score from validation signals. No Blueprint required — works on any validate result. Combines six weighted signals into a single confidence score: - Surface distance (how close to the constraint manifold) - Geometric health (projection quality, regulator, closure) - Anomaly score (structural fingerprint deviation) - Stability score (batch drift) - Motif compliance (pattern violations) - Motif gate (enforcement decision) Returns confidence level (high/medium/low) and a recommendation. Different from analyze_anomaly and check_drift: those tools perform new analysis on raw data. geometric_confidence is post-hoc — it digests an already-computed state_vector and returns a single confidence number. Use this when you have a state_vector from a prior validate / get_execution_trace call and want a one-line summary of structural quality. Use analyze_anomaly when you need to know why something is anomalous; use check_drift when you need to compare against historical observations. Args: api_key: GeodesicAI API key (starts with gai_) state_vector: State vector dictionary, typically the state_vector field from a validate or get_execution_trace result. Returns: confidence: float in [0, 1] level: "high" / "medium" / "low" recommendation: text recommendation for the caller signals: per-signal contribution breakdown signal_weights: weights used in the composite

check_realization

Run structural realization analysis on a payload. Embeds the payload via the Blueprint's declared embedding schema, projects it onto the Blueprint's reference subspace, and returns a realization score, residual, projection angle, and full report. The Blueprint must include a `realization` configuration block (see RealizationConfig in Platform_Agent.realization.schema). If no realization config is present, the report status is "skipped" and the payload is treated as unconstrained by the realization layer. For Blueprints using basis mode "auto", the first N payloads bootstrap the reference subspace; until the bootstrap pool is full, the report status is "skipped". After bootstrap, every subsequent payload is projected against the locked subspace and receives a real score. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: payload to analyze blueprint: Blueprint name (defaults to "default") Returns: dict with keys: status: "pass" | "review" | "skipped" realization_score: float in [0, 1], higher = better fit residual: ||v - P_U(v)|| angle_degrees: angle between v and P_U(v) in_subspace: bool — residual < tolerance basis_mode: "vectors" | "auto" | "uninitialized" basis_dimension: k of the reference subspace vector_dimension: D of the embedded payload report: full RealizationReport dict (may include invariance/stability stacks if enabled)

check_drift

Check whether the data pattern has shifted since previous observations. Works with or without a Blueprint. Monitors structural stability across a stream of data. Detects regime changes when the data's geometric embedding moves to a different region of the constraint space — indicating the source data's structure has fundamentally changed. Call this repeatedly as new data arrives to track drift over time. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: New data point to check for drift blueprint: Blueprint for geometric embedding context

authorize_execution

Decide whether an action should be allowed to proceed. Runs full validation, then applies the Blueprint's execution gate. Returns a simple allow/block decision with reasoning. Use this when your agent is about to take a real-world action (payment, filing, API call, data write) and needs a deterministic go/no-go. Different from validate: validate says "is this data correct?" authorize_execution says "should this action happen?" Args: api_key: GeodesicAI API key (starts with gai_) structured_data: The data associated with the action blueprint: Blueprint governing this action type

load_rule_pack

Load a prebuilt Blueprint template for fast onboarding. Rule Packs are ready-made governance configurations for common use cases. Call with no pack_id to list all available packs. Call with a pack_id to load the full configuration, then use create_blueprint to save it. Available packs include templates for: invoice governance, timecard/payroll governance, legal document governance, purchase order governance, and insurance claims governance. Each includes field definitions, derivation rules, constraints, and agent conditioning instructions. Args: api_key: GeodesicAI API key (starts with gai_) pack_id: ID of the rule pack to load. Omit to list available packs.

get_execution_trace

Run validation and return the detailed execution trace. Shows the exact sequence of validation nodes that ran, whether each was deterministic, and the runtime of each node. Use for debugging, compliance audits, or understanding exactly what the platform checked. Different from validate: validate returns the verdict (PASS / FAIL / REVIEW) and the state vector summary. get_execution_trace returns everything validate does PLUS the per-node trace records. Use validate for normal operation; use get_execution_trace when you need to see inside the pipeline (debugging, audit prep, latency analysis). The trace is the same whether validation passes or fails — every node that ran is recorded with its inputs, outputs, and timing. Args: api_key: GeodesicAI API key (starts with gai_) structured_data: The data to trace validation for blueprint: Blueprint to validate against. Caller must own the Blueprint. Returns: status: "PASS" / "FAIL" / "REVIEW" / "ERROR" determinism_hash: cryptographic hash of inputs + rules trace: ordered list of node records, each with: node_name, node_type, deterministic (bool), runtime_ms, inputs, outputs node_count: number of nodes in the trace deterministic_count: how many nodes were deterministic state_vector: same state_vector validate returns

verify_replay

Verify that two execution replay contracts represent the same deterministic result. This is the programmatic proof of GeodesicAI's core promise: same input + same rules = same result, every time. Given two replay contracts (e.g. from the original execution and a re-run), this tool compares all component hashes and reports whether the executions are byte-identical. Use this to: - Prove to an auditor that a decision from March 3rd matches a re-run today. - Detect when a rule change has altered execution behavior (input hash matches but canonical trace hash differs → the rules diverged). - Confirm a Blueprint migration didn't change any observable outcomes. Args: api_key: GeodesicAI API key (starts with gai_) contract_a: A replay contract dict (the `replay_contract` field from a prior validate/execute_task response) contract_b: Another replay contract dict to compare against contract_a Returns: replay_match: bool — True if the top-level replay_hash matches (fully identical) contract_version_match: bool matches: dict of field_name → value, for every field that agreed mismatches: dict of field_name → {expected, actual}, for every field that disagreed summary: plain-English one-liner describing the result Interpretation of mismatches: - input_payload_hash: the two runs were fed different data - template_version: the Blueprint was upgraded between runs - solver_registry_hash: the platform itself changed between runs - canonical_trace_hash: same inputs and rules but different execution path (should never happen under determinism; indicates a platform bug) - graph_hash: DAG topology changed between runs

account_status

Report the calling account's plan, key usage, and limits. Use this to introspect what the caller is allowed to do. Agents that hit rate limits or key-count caps can call this to explain the limit to the human and suggest upgrading if needed. Args: api_key: GeodesicAI API key (starts with gai_) Returns: plan: The user's current plan — one of pilot, trial, tier1, tier2, beta, enterprise plan_label: Human-readable plan name (e.g. "Personal Access", "Small Business") account_key_count: Number of account-level API keys currently issued account_key_limit: Maximum account keys allowed on this plan blueprint_count: Number of Blueprints owned by this user blueprint_limit: Maximum Blueprints allowed on this plan email: The user's email address (for reference in support) user_id: Stable user identifier trial_days_remaining: Days left on trial, if plan == "trial"; else null

delete_blueprint

Permanently delete a Blueprint and all of its API keys. DESTRUCTIVE — cannot be undone. Cascading effects: - The Blueprint's template_config.json is removed from disk. - All Blueprint-scoped API keys for this workflow are deleted. Any agents using those keys will start receiving auth errors on their next call. - The Blueprint is removed from the platform's template registry. Account-level keys are NOT affected. Only the per-Blueprint keys minted at create time (or via this Blueprint's UI) are revoked. Use list_blueprints first to confirm the workflow_name. The caller must own the Blueprint — cross-account deletion is rejected. Different from update_blueprint: update_blueprint replaces the config in place and keeps the API keys; delete_blueprint removes everything. Args: api_key: GeodesicAI API key (starts with gai_) workflow_name: Name of the Blueprint to delete (the same value used as 'blueprint' in validate) confirm: Must be set to true to actually delete. If false, the tool returns a preview of what would be deleted without performing the deletion. Default: false. Returns: status: "ok" | "preview" | "ERROR" deleted: workflow_name that was removed (only on ok) keys_revoked: number of Blueprint API keys revoked message: human-readable summary

update_blueprint

Update an existing Blueprint's configuration in place. Only fields you pass are updated; fields you omit keep their current values. To clear a list field (e.g. remove all rules), pass an explicit empty list []. Existing API keys for this Blueprint are preserved — agents using those keys continue working after the update. Ownership stamps are also preserved; you cannot transfer Blueprint ownership. The workflow_name itself cannot be renamed. To rename, create a new Blueprint with the new name and delete the old one. Different from create_blueprint: create_blueprint creates a new Blueprint and mints a fresh API key. update_blueprint modifies an existing one and returns no new key. Args: api_key: GeodesicAI API key (starts with gai_) workflow_name: Name of the Blueprint to update (must already exist) customer_name: New customer/project name. Pass None to keep current. mode: "observe" or "enforce". Pass None to keep current. extracted_fields: New list of agent-extracted fields. Pass None to keep current; pass [] to clear. derived_fields: New list of platform-derived fields. None or []. derivation_rules: New list of derivation rules. See blueprint_guide prompt for schema. None or []. formal_constraints: New list of constraints. See blueprint_guide prompt for schema. None or []. semantic_checks: New list of semantic checks. None or []. require_math: Override math validation flag. None to keep current. require_consistency: Override consistency flag. None to keep. require_coherence: Override coherence flag. None to keep. require_provenance: Override provenance flag. None to keep. require_high_assurance: Override high-assurance flag. None to keep. enable_anomaly_detection: Override anomaly flag. None to keep. enable_drift_tracking: Override drift flag. None to keep. Returns: status: "ok" | "ERROR" blueprint: workflow_name that was updated fields_changed: list of config keys that were modified field_count: new total of extracted + derived fields rule_count: new total of derivation rules constraint_count: new total of formal constraints

list_api_keys

List all API keys owned by the calling account. Returns a masked representation of each key plus a stable key_id (SHA-256 hash) that can be used with rotate_api_key and delete_api_key. Full key strings are NEVER returned by this tool. Each entry includes: - api_key: masked key string (e.g. "gai_***...REe0") - key_id: SHA-256 hash, usable as the target for rotate/delete - type: "account" or "blueprint" - intent: "All tools (account key)" or the Blueprint workflow_name - customer: associated customer/project name - created: ISO timestamp Args: api_key: GeodesicAI account-level API key (starts with gai_). Blueprint-scoped keys cannot list keys. Returns: status: "ok" | "ERROR" keys: list of key records with masked api_key and key_id total: number of keys returned

rotate_api_key

Rotate one of the caller's API keys. The old key stops working immediately; a new key with the same scope is issued. The new key inherits the old key's scope: - An account-level key rotates to another account-level key. - A Blueprint-scoped key rotates to a key for the same Blueprint. The target key can be specified two ways: - As the full key string (gai_...) — useful if you just received it. - As a key_id (SHA-256 hash from list_api_keys) — useful when you only have the masked version. Either is accepted. Args: api_key: GeodesicAI account-level API key (starts with gai_). Must be an account key. key_to_rotate: Either the full API key string OR the key_id (SHA-256 hex hash) returned by list_api_keys. Returns: status: "ok" | "ERROR" api_key: the new key string (copy this immediately) type: "account" | "blueprint" intent: Blueprint folder name, or empty for account keys

delete_api_key

Permanently delete one of the caller's API keys. DESTRUCTIVE — agents using the deleted key will receive auth errors immediately. The Blueprint a key was tied to (if any) is NOT affected; only the credential is revoked. To delete a Blueprint and all its keys, use delete_blueprint. The target key can be specified two ways: - As the full key string (gai_...). - As a key_id (SHA-256 hash from list_api_keys). Args: api_key: GeodesicAI account-level API key (starts with gai_). key_to_delete: Either the full API key string OR the key_id from list_api_keys. confirm: Must be true to actually delete. If false, returns a preview without deleting. Default: false. Returns: status: "ok" | "preview" | "ERROR" deleted: metadata about the deleted key (only on ok) message: human-readable summary