Skip to main content
Glama
xli431

corexense-mcp

by xli431
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

CoreXense-N: An MCP Evidence Gateway for Physical AI

Validate evidence, request bounded re-observation, and trace why a workflow pauses. The submission is a software review prototype. It does not control robot motors.

Run

Use Python 3.11+:

git clone https://github.com/xli431/corexense-n-hackathon.git
cd corexense-n-hackathon
python -m venv .venv
source .venv/bin/activate
python -m pip install -e '.[test]'
python -m pytest -q
python tools/run_mcp_sprint.py runs/offline-001

Open runs/offline-001/review.html. The runner uses actual MCP stdio communication. Default semantic reviews are explicit mocks; offline success is not a live-model result.

Related MCP server: Ackrite

NVIDIA and Nebius

First list the NVIDIA Nemotron models accessible to your account, with no inference:

python tools/run_mcp_sprint.py runs/catalog --live --prompt-key

Then pass one exact returned model ID:

python tools/run_mcp_sprint.py runs/live-001 --live --prompt-key --model EXACT_MODEL_ID

Credentials stay in a hidden local prompt. This walkthrough makes at most two inference calls unless an optional simulation episode is supplied (then three). There is no automatic retry. Nebius Token Factory hosts NVIDIA Nemotron semantic review. Local checks and elapsed evidence validity remain authoritative.

The cloud response may correctly result in HOLD after the 250 ms synthetic evidence window expires. That is not robot performance, a task failure rate, or a safety proof.

Recorded live check: three requests, 2,674 reported tokens. The recovery fixture received model ALLOW but remained HOLD because its evidence expired during the audit. Another response was truncated at the default 256-token output budget. Use --audit-max-tokens 1024 for a separately recorded budget follow-up; the freshness policy and strict response validation remain unchanged.

Build a verified summary from a completed run (no API requests):

python tools/build_evidence_report.py runs/live-001/mcp_report.json runs/live-summary-001

MCP tools

  • list_scenarios: list synthetic fixtures.

  • review_scenario: original local fruit qualification and trace.

  • review_episode: synthetic episode-bound semantic review and post-audit check.

  • explain_belief: synthetic delayed/conflicting evidence reconstruction.

  • review_simulation_episode: explicit FIRA JSON replay audit, always non-executable.

The server offers no actuator or arbitrary filesystem tools. Host configuration controls cloud access. corexense-mcp starts the stdio service after installation.

FIRA prior work and current integration

The existing MuJoCo/RoboSim produce scene and its UI remain separate work. An owner may supply a result.json / trace.jsonl episode directory using --simulation-episode /absolute/path/to/episode. Its integrity is checked and the same source hash is bound to the semantic review. This is historical auditing, not closed-loop inference controlling the simulated or physical robot.

Evaluation and limitations

python tools/run_robustness.py runs/robustness-001

This runs 1,920 synthetic policy evaluations and 17 injected transport contracts. These are fixture diagnostics, not independent physical trials or live model accuracy. The hash ledger detects changes relative to a retained tip; it does not authenticate the original source. Real fruit input remains blocked until a sensor adapter is commissioned. No supervised physical controller is included.

Source boundaries and prior work

The core derives from the existing CoreSense/CoreXense-N work; preserve the Apache license and notices. TWS-Belief is vendored under MIT with a pinned source manifest. Private operation_logging, review, perception, raw media, hardware calibration, FIRA upstream UI, and PEG research are excluded. No third-party dataset is bundled. The upstream TWS-Belief CLI/dataset adapters are not exposed by this demo; only the reconstruction API used by the MCP tool is qualified in this package.

See docs/REUSE_MAP.md for related projects. New sprint work: bound MCP episode review, simulation replay adapter, TWS-Belief tool, end-to-end client and reports. Live results, physical observations and future capabilities must be reported separately.

FIRA background acknowledgments: Voxel51 FiftyOne for data inspection, SKAI Intelligent for simulation support, and HawkRobo for earlier FIRA sponsorship. These credits do not imply a new partnership or endorsement of this submission.

Offline reproduction remains available after cloud credit expiry. New live inference requires valid Nebius account access.

See docs/SUBMISSION_STORY.md for the submission draft and docs/SPRINT_CLOSEOUT.md for verified results and remaining steps. SKAI course assets remain outside this repository. Local inspection opened the USD stage with no unresolved dependencies; simulator execution and training remain separate work.

For reproduction after cloud credits expire, see the judge runbook. The source export has been independently installed and verified with 103 tests, an installed MCP server launched outside the source tree, and the offline fault matrix.

Available Tools

5 tools
explain_beliefC

Explain delayed or conflicting synthetic evidence with TWS-Belief.

NameRequiredDescriptionDefault
caseYes

TDQS

C2.3/5.0
Behavior2/5

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

No annotations are provided, so the description must carry the behavioral burden. "Explain" weakly implies a read-only operation, but the description does not state permissions, side effects, output behavior, or any operational constraints.

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?

The description is a single front-loaded sentence with no filler. Its brevity is efficient, though some words ("TWS-Belief") are jargon rather than explanatory.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and an undocumented required parameter, the description is too thin to help an agent invoke the tool correctly. It states a high-level purpose but omits the input meaning and behavioral context needed for this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The sole required parameter, "case", has 0% schema description coverage and is never mentioned in the description. The agent receives no guidance on what a "case" is, its expected format, or what values are valid.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ("Explain") and names an object ("delayed or conflicting synthetic evidence") plus a system ("TWS-Belief"). However, "TWS-Belief" and "synthetic evidence" are opaque, and it does not distinguish this tool from its siblings such as review_scenario or review_episode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no explicit guidance on when to use this tool, when not to use it, or which sibling tools are alternatives. The single sentence implies a purpose but leaves selection entirely to inference.

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

list_scenariosA

List supported synthetic fruit decision scenarios and explicit limits.

NameRequiredDescriptionDefault

No parameters

TDQS

A3.5/5.0
Behavior3/5

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

With no annotations, the description carries the full burden. It implies a read-only enumeration and mentions that limits are included, but says nothing about return shape, ordering, pagination, or authorization. That is thin for an unannotated tool, though the zero-parameter surface limits the risk.

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?

The definition is a single front-loaded sentence with no wasted clauses. It loses a point only because the key phrase 'synthetic fruit decision scenarios' is opaque rather than precise.

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

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, zero-argument list tool this is adequate but not complete. It does not define what a 'supported' scenario is, what the 'explicit limits' refer to, or what the returned list contains, and there is no output schema to compensate.

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?

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain or get wrong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

It states a specific verb and resource ('List ... scenarios') and adds scope ('supported', 'explicit limits'). However, the domain term 'synthetic fruit decision scenarios' is unexplained and it does not explicitly contrast with the sibling review_scenario, so the agent must infer the distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Listing scenarios implies this is a discovery step before review_scenario, but the description never says when to use it, when not to, or that review_scenario is the follow-up. Usage is only implied.

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

review_episodeC

Review a synthetic fruit episode; cloud use is controlled by the host configuration.

NameRequiredDescriptionDefault
caseYes

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only that cloud use is host-controlled, and says nothing about whether reviewing is read-only, what side effects or permissions are involved, or what the operation returns.

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?

The description is one front-loaded sentence with no wasted wording. Its brevity is appropriate structurally, though the content is under-specified rather than overly verbose.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no annotations, no output schema, and an undocumented required parameter, the description does not provide enough context to invoke the tool confidently. It should at least clarify what a 'case' is and what reviewing produces.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single required parameter 'case' has 0% schema description coverage, and the description never explains what a case is or what format it expects. The schema only supplies the type and required status, leaving the parameter's meaning unclear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a verb and resource ('Review a synthetic fruit episode'), but 'review' is vague and 'fruit episode' is not explained. It only loosely distinguishes from siblings like review_scenario and review_simulation_episode, without saying what reviewing entails.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus list_scenarios, review_scenario, explain_belief, or review_simulation_episode. The note about cloud use being host-controlled is not a usage selection rule.

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

review_scenarioC

Run bounded local evidence qualification, returning a decision and trace.

NameRequiredDescriptionDefault
caseYes

TDQS

C2/5.0
Behavior2/5

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

With no annotations, the description carries the full behavioral burden. It discloses that the tool is 'bounded' and returns a decision and trace, but it does not state whether the operation is read-only or mutating, what 'bounded' means, whether it has side effects, or what permissions are required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence with no wasted words, so it is structurally concise and front-loaded. However, its brevity comes at the cost of under-specification rather than efficient clarity.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one undocumented parameter, no annotations, and no output schema, the description should explain usage and return semantics more fully. It mentions a decision and trace but does not clarify their structure or the meaning of the required 'case' input.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single required parameter 'case' has 0% schema description coverage, and the description adds no information about what a case is, its expected format, or how it affects the qualification. This leaves the only parameter entirely undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says it runs 'bounded local evidence qualification' and returns a decision and trace, but 'evidence qualification' is vague jargon rather than a concrete verb-resource statement. It does not clarify what a scenario is or how this differs from siblings like review_episode or review_simulation_episode.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance is provided. The description does not name alternatives or explain when an agent should choose review_scenario over list_scenarios, explain_belief, review_episode, or review_simulation_episode.

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

review_simulation_episodeC

Audit an explicit FIRA simulation replay bundle; never authorize execution.

NameRequiredDescriptionDefault
traceYes
reportYes

TDQS

C2.9/5.0
Behavior3/5

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

With no annotations provided, the description carries the full burden and does disclose an important boundary: this audit must never authorize execution. However, it does not state whether the tool mutates state, what permissions are required, what the audit returns, or how failures are handled.

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?

The description is a single front-loaded sentence with no filler, and the safety boundary is placed after the core purpose. It is concise, though the phrase 'explicit FIRA simulation replay bundle' is somewhat opaque without further context.

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

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with two required nested parameters, no annotations, no output schema, and 0% schema description coverage, this is not complete enough. It gives purpose and a safety constraint but leaves the agent without the information needed to construct or interpret the report and trace payloads.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has 0% description coverage and the description does not explain the required 'report' and 'trace' parameters at all. 'Replay bundle' hints that they belong together, but the agent gets no semantic mapping for either nested parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb/resource pair: audit a FIRA simulation replay bundle. That is clear enough to distinguish it from generic review tools, though it does not explicitly contrast with siblings such as review_episode or review_scenario.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intended context is implied by 'simulation replay bundle', but there is no explicit when-to-use guidance or routing versus sibling review tools. The phrase 'never authorize execution' is a safety constraint rather than a selection guideline.

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. 5 tool updatesv0.2.0
    • First observedexplain_belief
    • First observedlist_scenarios
    • First observedreview_episode
    • First observedreview_scenario
    • First observedreview_simulation_episode
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.9/5.0

Scored across 5 tools

Disambiguation3/5

Three of the five tools (review_scenario, review_episode, review_simulation_episode) share the same 'review_*' verb and closely related semantics; descriptions differentiate them (local qualification vs. synthetic episode vs. FIRA replay audit), but the scenario-vs-episode boundary remains fuzzy and invites misselection. list_scenarios and explain_belief are clearly distinct.

Naming Consistency5/5

All five names follow a consistent snake_case verb_noun pattern (list_scenarios, review_scenario, explain_belief, review_episode, review_simulation_episode). No mixed conventions or casing deviations.

Tool Count5/5

Five tools is well within the sweet spot for a narrowly scoped decision-review server. Each tool maps to a distinct capability (enumeration, review, explanation, episode audit, simulation audit) and none appear redundant padding.

Completeness3/5

The surface covers enumeration, review, explanation, and replay auditing, but there is no tool to fetch or inspect a specific scenario/episode by identifier, nor to list available episodes or query belief state directly. These are notable gaps that could force agents into dead ends after listing.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Ackrite

    mshanghai570
    A
    license
    B
    quality
    C
    maintenance
    Enables AI agents to verify technical claims against supplied evidence, identify unsupported assumptions and contradictions, and recommend the smallest next check before acting.
    5
    MIT

  • riposte

    SorenSocordia
    A
    license
    Not graded
    quality
    B
    maintenance
    Enables deterministic verification of AI agent decisions and actions, providing PASS/FAIL/ABSTAIN verdicts with replayable proofs and an optional signed receipt ledger.
    5 npm
    Apache 2.0

  • io.github.loopg/pramana-mcp

    reliai-in
    A
    license
    A
    quality
    B
    maintenance
    Lets an assistant read recorded production AI agent runs — steps, model and tool calls with arguments, and outcomes — along with the findings of comparison runs that checked a prompt or model change against those recordings, and verify a signed evidence bundle offline with no account or network. It is strictly read-only: no tool starts a replay or comparison, so nothing can spend money or act without a person deciding.
    5
    Apache 2.0