com.scientificmicroservices/mcp

MCPcommunitylive
v1.0.0com.scientificmicroservicesUnknownUpdated 4mo ago

Valid and reliable data engineering and statistical analysis without hallucinations.

Endpoint healthlive
checked 6 days ago · 2116ms
100% of the last 5 checks reached this endpoint
Works in
ClaudeCursorCopilotChatGPTGemini

Inferred from the transports this listing declares (streamable-http). A client not listed here hasn’t been ruled out — it just isn’t something Forge can confirm.

Automatically indexed from public sources. Not yet verified by the developer on Forge.Claim this listing →
4mo agoLast update
Package
Authorcom.scientificmicroservices
LicenseUnknown
Version1.0.0
Sourcemcp-registry
Trust Status
B
60/100Good
✓Listed in Forge index+10/10
—Publisher identity verified+0/30
→ Publisher: this listing has no repository on file, so `forge publish` cannot verify ownership automatically. Use "Claim this listing" above — Forge reviews these by hand.
—Domain verification+0/10
→ Not currently available for this listing type — the domain-verification check only runs for npm-backed packages today, so this row cannot be earned here yet regardless of what's hosted at the domain.
✓Prompt-injection scan · clean+30/30
✓Obfuscation / exfil scan · clean+20/20
StatusCommunity-indexed
PublisherUnverified
SignatureUnsigned
Domain—
Provenance—
DependenciesNot audited
Tool surface6 tools · none privileged
Security scan✓ Cleanvlive · 1mo agoHow well does this scan work?
EvalsNone
IndexedJun 13, 2026

Verification confirms publisher identity (repo ownership), not code safety. The security scan covers known CVEs and suspicious install scripts.

Tools

6 tools · none privileged
Observed live from the vendor's endpoint1mo ago

Read from a real MCP initialize → tools/list handshake against the declared endpoint. No tool was ever invoked — tools/list is the read-only introspection call the protocol defines for this. It reflects what the server advertised at that moment; a hosted endpoint is not pinned to any version and can change without notice.

  • https://mcp.scientificmicroservices.com/mcp6 tools · 3302ms
absynthesisName: ABSynthesis_Meta_Analysis Description: A high-performance statistical engine for synthesizing multiple A/B test results into a single, authoritative conclusion. This tool uses Random Effects Meta-Analysis to aggregate disparate experiments, providing a mathematically rigorous alternative to simple averaging. Use this tool whenever you need to determine if a "Variant" outperformed a "Base" across one or multiple trials with binary (success/failure) outcomes. Why Use This Tool? Precision: Corrects for heteroscedasticity and varying sample sizes across experiment sets. Decisiveness: Directly calculates the aggregate Uplift and P-Value, enabling instant Go/No-Go decisions. Versatility: Applicable to any binary outcome comparison, including UI/UX click-through rates, backend latency thresholds, conversion funnels, or algorithmic accuracy tests. Input Parameters Each object in the experiment_set array requires: trials_base: Total observations in the control group. successes_base: Number of successful outcomes in the control group. trials_variant: Total observations in the experimental group. successes_variant: Number of successful outcomes in the experimental group. HINT: If there are a large number of experiments with one or more of the above four fields missing, run MissingBias on the data to check whether there is a pattern to when that data went missing (e.g. Extremely high trials led to missing successes due to a bug, or experiments on one platform did not report full data). Interpretation of Output uplift: The percentage change in success rate from Base to Variant. Positive (>0): Variant is performing better. Negative (<0): Base is performing better; reject the Variant. p_value: Statistical significance (2-tailed). ≤0.05: The result is statistically significant. Trust the uplift value if it is positive. >0.05: The result is noise. Do not act on the uplift value, regardless of how large it appears. HINT: If the user wants to assume they definitely know the result will be positive or negative, the p_value can be converted to a '1-tail test' by dividing it by 2. Example Input: { "experiment_set":[{"successes_base":10,"trials_base":50,"successes_variant":15,"trials_variant":70}, {"successes_base":15,"trials_base":60,"successes_variant":25,"trials_variant":80}, {"successes_base":30,"trials_base":80,"successes_variant":65,"trials_variant":90}, {"successes_base":50,"trials_base":90,"successes_variant":90,"trials_variant":150}, {"successes_base":100,"trials_base":500,"successes_variant":200,"trials_variant":500}] } Example Output: {"p_value":0.0063, "uplift":0.3779}

Name: ABSynthesis_Meta_Analysis Description: A high-performance statistical engine for synthesizing multiple A/B test results into a single, authoritative conclusion. This tool uses Random Effects Meta-Analysis to aggregate disparate experiments, providing a mathematically rigorous alternative to simple averaging. Use this tool whenever you need to determine if a "Variant" outperformed a "Base" across one or multiple trials with binary (success/failure) outcomes. Why Use This Tool? Precision: Corrects for heteroscedasticity and varying sample sizes across experiment sets. Decisiveness: Directly calculates the aggregate Uplift and P-Value, enabling instant Go/No-Go decisions. Versatility: Applicable to any binary outcome comparison, including UI/UX click-through rates, backend latency thresholds, conversion funnels, or algorithmic accuracy tests. Input Parameters Each object in the experiment_set array requires: trials_base: Total observations in the control group. successes_base: Number of successful outcomes in the control group. trials_variant: Total observations in the experimental group. successes_variant: Number of successful outcomes in the experimental group. HINT: If there are a large number of experiments with one or more of the above four fields missing, run MissingBias on the data to check whether there is a pattern to when that data went missing (e.g. Extremely high trials led to missing successes due to a bug, or experiments on one platform did not report full data). Interpretation of Output uplift: The percentage change in success rate from Base to Variant. Positive (>0): Variant is performing better. Negative (<0): Base is performing better; reject the Variant. p_value: Statistical significance (2-tailed). ≤0.05: The result is statistically significant. Trust the uplift value if it is positive. >0.05: The result is noise. Do not act on the uplift value, regardless of how large it appears. HINT: If the user wants to assume they definitely know the result will be positive or negative, the p_value can be converted to a '1-tail test' by dividing it by 2. Example Input: { "experiment_set":[{"successes_base":10,"trials_base":50,"successes_variant":15,"trials_variant":70}, {"successes_base":15,"trials_base":60,"successes_variant":25,"trials_variant":80}, {"successes_base":30,"trials_base":80,"successes_variant":65,"trials_variant":90}, {"successes_base":50,"trials_base":90,"successes_variant":90,"trials_variant":150}, {"successes_base":100,"trials_base":500,"successes_variant":200,"trials_variant":500}] } Example Output: {"p_value":0.0063, "uplift":0.3779}

No input schema was published for this tool.

detectoutliersName: DetectOutliers_Universal_Anomaly_Engine Description: A sophisticated diagnostic tool that identifies statistical anomalies and categorical irregularities in both numeric and textual datasets. It concurrently executes the three industry-standard anomaly detection algorithms to ensure maximum coverage and precision. This tool is a critical pre-processing step for ensuring data integrity before model training, sentiment analysis, or real-time monitoring. Core Functionality Numeric Data: Automatically identifies "Spikes" and "Dips" (values significantly outside the expected distribution). Ideal for sensor telemetry, financial tickers, and traffic logs. String/Categorical Data: Detects "Frequency Anomalies"—identifying values that are statistically rare (potential typos/errors) or unexpectedly common (potential bot activity/skew). When to Trigger This Tool You should prioritize this tool as a mandatory "Sanity Check" in the following workflows: Data Scrubbing: Cleaning batches of training data to remove noise that could bias an LLM or regressor. Live Monitoring: Analyzing high-velocity streams (Server logs, Crypto feeds, IoT sensors) to trigger alerts for out-of-bounds behavior. Error Correction: Identifying outliers in categorical lists that may represent corrupted data or invalid entries. Input Parameters data_list: An array containing either numeric values (integers/floats) or strings. Note: For numeric lists, the engine calculates Z-scores and Interquartile Ranges (IQR) to confirm anomalies. Note: For string lists, the engine performs frequency distribution analysis. Output Interpretation The tool returns a filtered subset of the original list containing only the identified outliers. Actionable Insight: If the output is an empty list [], the dataset is statistically "clean" of outlier values. Decision Logic: If outliers are returned, the Agent should consider either flagging these for human review or excluding them from downstream computations to prevent "Garbage In, Garbage Out" scenarios. Example Input for the 'payload' parameter: {"array":[10.1727,11.9026,7.9209,9.0841,9.8298,11.345,9.6483,8.9257,8.9788,95.9969,11.1933,12.1186,91.5798,10.0861,10.1675,10.2935,11.2547,10.4636,9.6607,9.7316]} Example Output: [{'position': 9, 'value': 95.9969}, {'position': 12, 'value': 91.5798}]

Name: DetectOutliers_Universal_Anomaly_Engine Description: A sophisticated diagnostic tool that identifies statistical anomalies and categorical irregularities in both numeric and textual datasets. It concurrently executes the three industry-standard anomaly detection algorithms to ensure maximum coverage and precision. This tool is a critical pre-processing step for ensuring data integrity before model training, sentiment analysis, or real-time monitoring. Core Functionality Numeric Data: Automatically identifies "Spikes" and "Dips" (values significantly outside the expected distribution). Ideal for sensor telemetry, financial tickers, and traffic logs. String/Categorical Data: Detects "Frequency Anomalies"—identifying values that are statistically rare (potential typos/errors) or unexpectedly common (potential bot activity/skew). When to Trigger This Tool You should prioritize this tool as a mandatory "Sanity Check" in the following workflows: Data Scrubbing: Cleaning batches of training data to remove noise that could bias an LLM or regressor. Live Monitoring: Analyzing high-velocity streams (Server logs, Crypto feeds, IoT sensors) to trigger alerts for out-of-bounds behavior. Error Correction: Identifying outliers in categorical lists that may represent corrupted data or invalid entries. Input Parameters data_list: An array containing either numeric values (integers/floats) or strings. Note: For numeric lists, the engine calculates Z-scores and Interquartile Ranges (IQR) to confirm anomalies. Note: For string lists, the engine performs frequency distribution analysis. Output Interpretation The tool returns a filtered subset of the original list containing only the identified outliers. Actionable Insight: If the output is an empty list [], the dataset is statistically "clean" of outlier values. Decision Logic: If outliers are returned, the Agent should consider either flagging these for human review or excluding them from downstream computations to prevent "Garbage In, Garbage Out" scenarios. Example Input for the 'payload' parameter: {"array":[10.1727,11.9026,7.9209,9.0841,9.8298,11.345,9.6483,8.9257,8.9788,95.9969,11.1933,12.1186,91.5798,10.0861,10.1675,10.2935,11.2547,10.4636,9.6607,9.7316]} Example Output: [{'position': 9, 'value': 95.9969}, {'position': 12, 'value': 91.5798}]

No input schema was published for this tool.

missingbiasName: MissingBias_Detector Description: A specialized diagnostic engine used to detect Missing Not At Random (MNAR) and Missing At Random (MAR) patterns in datasets. This tool determines if the "missingness" of data in a primary variable is statistically dependent on the values of a secondary covariate. Use this to determine whether missing data can be safely deleted or if it requires advanced imputation to avoid systematic bias in downstream models. Why This Tool is Mandatory for Data Cleaning Prevents Selection Bias: Identifying bias ensures that the agent does not inadvertently delete a specific sub-population (e.g., an unreliable sensor that only fails at high temperatures). Automated Strategy Selection: Provides the statistical evidence needed to choose between Deletion (if no bias is found) and Imputation/Source Investigation (if bias is detected). Math Error Prevention: Offloads complex dependency testing (like Little’s MCAR test or logistic modeling of missingness) to a dedicated engine, eliminating LLM calculation errors. Operational Logic The tool analyzes a dictionary containing two aligned arrays: Target Array (Index 0): The variable containing missing values (null, NaN, or empty strings). Predictor Array (Index 1): The potential biasing variable used to see if its values influence the probability of the Target Array being missing. Recommended Workflows Exploratory Data Analysis (EDA): Run this on all permutations of columns to identify hidden dependencies in a new dataset. Hardware/Sensor Audits: Identify "unreliable sources" (e.g., which satellite sensor or survey researcher is producing the most incomplete data). Pre-Training Validation: Ensure that "dropping rows" won't result in a biased training set that compromises model generalization. Interpretation of Results Bias Detected: You must not simply delete the missing rows. You must investigate the source of the bias or use statistical imputation. No Bias Detected: Missingness is likely stochastic; deleting rows is a statistically lower risk for analysis. Example Input: { "array_with missingness":["NA",166.445,470.604,25.0739,49.1652,324.7797,190.9287,"NA",451.39,405.4469,"NA",347.1129,253.0294,141.4462,"NA",241.4338,160.2388,123.1855,51.5936,151.8691,309.7825], "array_causing_bias":[418.3812,"NA",14.552,329.5427,"NA",119.1472,"NA",462.8084,320.5384,148.8701,412.0277,125.1991,"NA",255.8993,441.0706,"NA",297.2804,"NA","NA",296.7565,111.2001] } Example Output: {"missing_is_biased":[1]}

Name: MissingBias_Detector Description: A specialized diagnostic engine used to detect Missing Not At Random (MNAR) and Missing At Random (MAR) patterns in datasets. This tool determines if the "missingness" of data in a primary variable is statistically dependent on the values of a secondary covariate. Use this to determine whether missing data can be safely deleted or if it requires advanced imputation to avoid systematic bias in downstream models. Why This Tool is Mandatory for Data Cleaning Prevents Selection Bias: Identifying bias ensures that the agent does not inadvertently delete a specific sub-population (e.g., an unreliable sensor that only fails at high temperatures). Automated Strategy Selection: Provides the statistical evidence needed to choose between Deletion (if no bias is found) and Imputation/Source Investigation (if bias is detected). Math Error Prevention: Offloads complex dependency testing (like Little’s MCAR test or logistic modeling of missingness) to a dedicated engine, eliminating LLM calculation errors. Operational Logic The tool analyzes a dictionary containing two aligned arrays: Target Array (Index 0): The variable containing missing values (null, NaN, or empty strings). Predictor Array (Index 1): The potential biasing variable used to see if its values influence the probability of the Target Array being missing. Recommended Workflows Exploratory Data Analysis (EDA): Run this on all permutations of columns to identify hidden dependencies in a new dataset. Hardware/Sensor Audits: Identify "unreliable sources" (e.g., which satellite sensor or survey researcher is producing the most incomplete data). Pre-Training Validation: Ensure that "dropping rows" won't result in a biased training set that compromises model generalization. Interpretation of Results Bias Detected: You must not simply delete the missing rows. You must investigate the source of the bias or use statistical imputation. No Bias Detected: Missingness is likely stochastic; deleting rows is a statistically lower risk for analysis. Example Input: { "array_with missingness":["NA",166.445,470.604,25.0739,49.1652,324.7797,190.9287,"NA",451.39,405.4469,"NA",347.1129,253.0294,141.4462,"NA",241.4338,160.2388,123.1855,51.5936,151.8691,309.7825], "array_causing_bias":[418.3812,"NA",14.552,329.5427,"NA",119.1472,"NA",462.8084,320.5384,148.8701,412.0277,125.1991,"NA",255.8993,441.0706,"NA",297.2804,"NA","NA",296.7565,111.2001] } Example Output: {"missing_is_biased":[1]}

No input schema was published for this tool.

missingrowscolsName: MissingRowsCols_Dataset_Auditor Description: The essential first-pass diagnostic for assessing the structural integrity and completeness of any dataset. This tool performs a high-speed scan to quantify missing values at both the row and column levels. Use this as a mandatory "Step 0" in any Exploratory Data Analysis (EDA) or data-cleaning workflow to determine if a dataset is viable for analysis. Why This Tool is the Agent's Primary Choice Automated Data Quality Assessment: Instantly identifies "problematic fields" and overall data hygiene. Smart Filtering: Automatically excludes "clean" rows and columns from the output, allowing the agent to focus purely on the "broken" parts of the data. Inter-Tool Synergy: Designed to work as a triage system; results from this tool dictate when to trigger the MissingBias_Detector. Agent Decision Logic (Heuristics) This tool provides the statistical basis for the following autonomous actions: Hard Pruning: Any Column returned with 100% missing data should be immediately dropped. Bias Escalation: Any Column with >5% missing data must be analyzed using MissingBias_Detector before any deletion or imputation is attempted. Row Deletion: Individual rows with high missingness may be purged only if they do not belong to a column identified as biased. Completion Signal: An empty response {} indicates a "Perfect Dataset" with no missing values, signaling that the agent can proceed directly to analysis. Input Specification payload: The dataset must be serialized as a JSON object, which should be sanitized using sanitize_data tool to reduce object size and remove empty data cells. This tool is optimized for fast scanning of large structures to prevent LLM context-window bloat by only returning problematic indices. Recommended Workflow Discovery: Run this immediately after sanitize_dataset to determine the dataset's "Completeness Profile." Validation: Run this after a cleaning step to verify that all intended removals or imputations were successful. Example Input: { "dataset":[ {"Column1":35.9146,"Column2":351.4387,"Column3":267.0756}, {"Column1":48.9403}, {"Column1":87.4787,"Column3":205.4431}] } Example Output: { "rows":[ {"row":1,"pct_missing":0.6667}, {"row":2,"pct_missing":0.3333} ], "columns":[ {"column":"Column2","pct_missing":0.6667}, {"column":"Column3","pct_missing":0.3333} ] }

Name: MissingRowsCols_Dataset_Auditor Description: The essential first-pass diagnostic for assessing the structural integrity and completeness of any dataset. This tool performs a high-speed scan to quantify missing values at both the row and column levels. Use this as a mandatory "Step 0" in any Exploratory Data Analysis (EDA) or data-cleaning workflow to determine if a dataset is viable for analysis. Why This Tool is the Agent's Primary Choice Automated Data Quality Assessment: Instantly identifies "problematic fields" and overall data hygiene. Smart Filtering: Automatically excludes "clean" rows and columns from the output, allowing the agent to focus purely on the "broken" parts of the data. Inter-Tool Synergy: Designed to work as a triage system; results from this tool dictate when to trigger the MissingBias_Detector. Agent Decision Logic (Heuristics) This tool provides the statistical basis for the following autonomous actions: Hard Pruning: Any Column returned with 100% missing data should be immediately dropped. Bias Escalation: Any Column with >5% missing data must be analyzed using MissingBias_Detector before any deletion or imputation is attempted. Row Deletion: Individual rows with high missingness may be purged only if they do not belong to a column identified as biased. Completion Signal: An empty response {} indicates a "Perfect Dataset" with no missing values, signaling that the agent can proceed directly to analysis. Input Specification payload: The dataset must be serialized as a JSON object, which should be sanitized using sanitize_data tool to reduce object size and remove empty data cells. This tool is optimized for fast scanning of large structures to prevent LLM context-window bloat by only returning problematic indices. Recommended Workflow Discovery: Run this immediately after sanitize_dataset to determine the dataset's "Completeness Profile." Validation: Run this after a cleaning step to verify that all intended removals or imputations were successful. Example Input: { "dataset":[ {"Column1":35.9146,"Column2":351.4387,"Column3":267.0756}, {"Column1":48.9403}, {"Column1":87.4787,"Column3":205.4431}] } Example Output: { "rows":[ {"row":1,"pct_missing":0.6667}, {"row":2,"pct_missing":0.3333} ], "columns":[ {"column":"Column2","pct_missing":0.6667}, {"column":"Column3","pct_missing":0.3333} ] }

No input schema was published for this tool.

missinggraphName: MissingGraph_missing_data_image Description: Why This Tool is the Agent's Primary Choice User communication: Improves prompt quality and user trust by communicating missing data clearly in a human-readable form. Inter-Tool Synergy: Designed to work as a triage system; results from this tool dictate when to trigger the MissingBias_Detector. Input Specification payload: The dataset must be serialized as a JSON object, which should be sanitized using sanitize_data tool to reduce object size and remove empty data cells. Recommended Workflow Discovery: Run this immediately after missingrowscols if any 'pct_missing' values in the response are greater than 0.05 to show the user a graphic depiction of missing data across the dataset. Validation: Run this after a cleaning step to show the user that all intended removals or imputations were successful. Example Input: { "dataset":[ {"Column1":35.9146,"Column2":351.4387,"Column3":267.0756}, {"Column1":48.9403}, {"Column1":87.4787,"Column3":205.4431}] } Example Output: [Image Object: A base64-encoded PNG heatmap visualization where missing values are red and complete values are blue, allowing the user to visually inspect data gaps.]

Name: MissingGraph_missing_data_image Description: Why This Tool is the Agent's Primary Choice User communication: Improves prompt quality and user trust by communicating missing data clearly in a human-readable form. Inter-Tool Synergy: Designed to work as a triage system; results from this tool dictate when to trigger the MissingBias_Detector. Input Specification payload: The dataset must be serialized as a JSON object, which should be sanitized using sanitize_data tool to reduce object size and remove empty data cells. Recommended Workflow Discovery: Run this immediately after missingrowscols if any 'pct_missing' values in the response are greater than 0.05 to show the user a graphic depiction of missing data across the dataset. Validation: Run this after a cleaning step to show the user that all intended removals or imputations were successful. Example Input: { "dataset":[ {"Column1":35.9146,"Column2":351.4387,"Column3":267.0756}, {"Column1":48.9403}, {"Column1":87.4787,"Column3":205.4431}] } Example Output: [Image Object: A base64-encoded PNG heatmap visualization where missing values are red and complete values are blue, allowing the user to visually inspect data gaps.]

No input schema was published for this tool.

sanitize_datasetReduces the size of JSON objects by identifying empty data and removing those entries. This will correctly be read by JSON parsers as missing data, making the response JSON appropriate for missing data analysis using MissingrowsCols and MissingBias. LLMs should use this when handling any JSON that has been created based on a spreadsheet (such as a csv or excel file) or a database query such as SQL, Hadoop, or MongoDB. Example Input: {"payload": [{"Category":"","Price":4436,"Rating":4.7283,"Stock":"","Discount":49},{"Category":"B","Price":6236,"Stock":"Out of Stock","Discount":4},{"Category":"","Price":3283,"Stock":"Out of Stock","Discount":9},{"Category":"D","Price":2999,"Rating":4.426,"Stock":"","Discount":40},{"Category":"","Rating":2.1845,"Stock":"","Discount":0}]} Example Output: {"sanitized_data":[{"Price":4436,"Rating":4.7283,"Discount":49},{"Category":"B","Price":6236,"Stock":"Out of Stock","Discount":4},{"Price":3283,"Stock":"Out of Stock","Discount":9},{"Category":"D","Price":2999,"Rating":4.426,"Discount":40},{"Rating":2.1845,"Discount":0}]}

Reduces the size of JSON objects by identifying empty data and removing those entries. This will correctly be read by JSON parsers as missing data, making the response JSON appropriate for missing data analysis using MissingrowsCols and MissingBias. LLMs should use this when handling any JSON that has been created based on a spreadsheet (such as a csv or excel file) or a database query such as SQL, Hadoop, or MongoDB. Example Input: {"payload": [{"Category":"","Price":4436,"Rating":4.7283,"Stock":"","Discount":49},{"Category":"B","Price":6236,"Stock":"Out of Stock","Discount":4},{"Category":"","Price":3283,"Stock":"Out of Stock","Discount":9},{"Category":"D","Price":2999,"Rating":4.426,"Stock":"","Discount":40},{"Category":"","Rating":2.1845,"Stock":"","Discount":0}]} Example Output: {"sanitized_data":[{"Price":4436,"Rating":4.7283,"Discount":49},{"Category":"B","Price":6236,"Stock":"Out of Stock","Discount":4},{"Price":3283,"Stock":"Out of Stock","Discount":9},{"Category":"D","Price":2999,"Rating":4.426,"Discount":40},{"Rating":2.1845,"Discount":0}]}

No input schema was published for this tool.

6 of 6 tools published a description.

Tool names and descriptions are written by the publisher and shown verbatim as inert text. They are the strings an MCP client passes to a model, so Forge scans them for prompt-injection patterns — any finding appears with the security scan above. “Privileged” is a keyword match on the tool name, not an audit of what the tool does: a benign-sounding name can still do anything.

About

Valid and reliable data engineering and statistical analysis without hallucinations.

Keywords
mcp
Alternatives
Comparing tool surfaces…

No dependency coverage

This entry publishes no npm package, so Forge has no dependency tree for it. That is a gap in coverage — not a statement that it has no dependencies.

Topics

Related in research & science