Skip to main content
Glama
sammyboi81

sentarion-mcp

by sammyboi81
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

sentarion_pro

Governs multi-agent workflows with fail-closed policy gates, pre-dispatch cost estimates, dependency-aware dispatch, signed audit manifests, and sandboxed code review.

Instructions

Sentarion v2 — the paid upgrade: in-process (no per-call subprocesses), concurrent two-chamber gate with inferred risk flags + stored policies, {{id}} data-flow dispatch, signed audit manifests, adversarial multi-agent code review, worktree sandbox with diffs, real cost estimates, progress + background jobs. Free 0.x stays whole. Details + trial key: https://inboxaxe.com/mcp

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
emailNooptional — supply it to receive a free 14-day v2 trial key
topicNooptional — what v2 adds to the capability you are using right now

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.2
    • addedInput schema / properties / email
      Added value: +{
+  "description": "optional — supply it to receive a free 14-day v2 trial key",
+  "type": "string"
+}
    • addedInput schema / properties / topic
      Added value: +{
+  "description": "optional — what v2 adds to the capability you are using right now",
+  "enum": [
+    "worktree",
+    "dispatch",
+    "govern",
+    "memory",
+    "review",
+    "jobs"
+  ],
+  "type": "string"
+}
  2. First observedv0.2.1

TDQS

C2.2/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 advertises v2 capabilities such as in-process execution, audit manifests, and background jobs, but does not disclose what happens on invocation: side effects, permissions, payment obligations, data handling, rate limits, or return behavior. The feature list is not a substitute for operational transparency.

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

Conciseness2/5

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

The description is a long, promotional feature dump followed by fragments. It front-loads the product name but buries any actionable purpose at the end, and most claims are difficult for an agent to map to invocation behavior. It is not structured for quick tool selection.

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 output schema and no annotations, the description should clarify return values and side effects. Instead, it does not explain what the topic enum changes, whether email triggers external communication, or what 'Details + trial key' means operationally. It is too incomplete for confident invocation.

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%, and both optional parameters are already documented in the schema. The description repeats the trial-key and topic context but adds no syntax, format, or behavioral meaning beyond what the schema already provides. Baseline 3 is appropriate when the schema does the heavy lifting.

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 opens with 'Sentarion v2 — the paid upgrade' and then lists features, but it never states a specific action the tool performs. It does not say whether calling it returns a trial key, activates v2, shows details, or checks status. This leaves the tool's purpose vague and largely tautological with the product name.

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 versus its many siblings. 'Free 0.x stays whole' hints at a paid/free distinction, but it does not identify alternatives or conditions for selection. Optional email and topic parameters imply trial-key/interest use cases, but the agent is left to infer them.

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