Superseded listing, not a dead server. This entry was imported from an early Glama registration under com.moltlinestudio.mcp; the same server is listed under its official MCP Registry name — use com.moltlinestudio/data. Endpoint unchanged: https://mcp.moltlinestudio.com/data — still live, still free on the free tier. Only this duplicate entry is deprecated.
Paste-your-data analytics over MCP, computed in code: csv_profile profiles columns and data quality, ab_test runs two-proportion z-tests, correlation and growth_rates cover the basics, with funnel_report, cohort_retention, and forecast_trend in the premium tier. No uploads, no external calls, no data retention.
Scored across 7 tools
Each tool targets a clearly distinct analytical task (A/B test, retention, correlation, CSV profiling, forecasting, funnel, growth), and every description explicitly states when to use it and which sibling tool to use instead. The built-in cross-references ('Not for X, use Y') leave essentially no overlap or ambiguity.
All seven names are lowercase snake_case and follow a consistent domain-concept naming pattern (ab_test, cohort_retention, correlation, csv_profile, forecast_trend, funnel_report, growth_rates). No mixed conventions or stray verb styles.
Seven tools is well within the ideal 3-15 range and each maps to a genuinely different analytical operation. There is no filler or redundancy in the set.
The surface covers the core analytics lifecycle: data profiling, growth, correlation, A/B testing, funnels, retention, and forecasting. Minor gaps exist (e.g. continuous-outcome significance testing, which ab_test explicitly excludes, and no aggregation or segmentation helper), but agents can work around them.
Run a two-proportion A/B significance test with a plain-language verdict. FREE.
Typical input {"conversions_a": 120, "visitors_a": 2400, "conversions_b": 156, "visitors_b": 2380} returns {"rate_a_pct": 5.0, "rate_b_pct": 6.55, "relative_lift_pct": 31.1, "z_score": ..., "p_value": ..., "significant_at_95": true, "verdict": "B beats A: statistically significant"}.
Use when exactly two variants each have a trial count and a conversion count. Not for continuous outcomes such as revenue per user, and not for three or more variants. Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need visitors > 0 and 0 <= conversions <= visitors"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| visitors_a | Yes | Visitors in variant A; must be at least 1. | |
| visitors_b | Yes | Visitors in variant B; must be at least 1. | |
| conversions_a | Yes | Conversions in variant A; 0 or more, at most visitors_a. | |
| conversions_b | Yes | Conversions in variant B; 0 or more, at most visitors_b. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive behavior, but the description adds substantial extra context: it is FREE, it never raises protocol errors, it returns a structured {"error": ...} on invalid input, and retries are safe after correction. These are exactly the operational details an agent needs beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, followed by usage constraints, an example, and error behavior. The example output is somewhat detailed, but every section contributes useful information; no sentence is clearly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even though an output schema exists, the description still provides an example output shape and error semantics. Combined with the annotations covering safety and the schema covering all parameters, the definition is complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and all four parameters are documented with types and bounds, so the baseline is 3. The description adds a concrete example input showing typical magnitudes (120/2400 and 156/2380), but it does not add new semantic constraints beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Run a two-proportion A/B significance test with a plain-language verdict.' This distinguishes it clearly from the sibling tools (cohort_retention, correlation, csv_profile, forecast_trend, funnel_report, growth_rates), none of which perform hypothesis testing. An agent can identify the operation without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit positive and negative conditions: 'Use when exactly two variants each have a trial count and a conversion count. Not for continuous outcomes such as revenue per user, and not for three or more variants.' However, it does not name a sibling alternative for the excluded cases, so routing is slightly less complete than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a retention table and average curve from raw cohort counts. PREMIUM (license).
Typical input {"cohorts": {"2026-01": [1000, 400, 300, 250]}} (index 0 is cohort size, each later index is users still active in that period) returns {"retention_table_pct": {"2026-01": [100.0, 40.0, 30.0, 25.0]}, "avg_curve_pct": [...], "reading": "..."}.
Use when each cohort has counts per period since acquisition. Not for a one-pass funnel (funnel_report). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "cohort '' must map to a list of numbers,"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| cohorts | Yes | Mapping of cohort label to a list of counts, where counts[0] is the cohort size and counts[n] is users active in period n, e.g. {"2026-01": [1000, 400, 300]}. The first 24 cohorts are used. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds context they cannot: the PREMIUM license gate, and a precise error contract stating the tool never raises a protocol error but returns {"error": ...} with fix guidance, making retry-after-correction safe. The one sentence restating read-only/idempotent is redundant with annotations but harmless.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose and PREMIUM flag are front-loaded, then input/output shape, then usage and error semantics — a sensible order. The inline input/output example is long and overlaps the output schema, but it earns most of its space by disambiguating the nested count convention.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analytical tool with an output schema and rich annotations, this covers everything an agent needs: input shape, output shape, licensing, error behavior, retry safety, and sibling routing. No material gap remains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents the index-0-is-cohort-size convention and the 24-cohort cap. The description adds a concrete worked example that makes the positional convention unambiguous, going modestly beyond the schema rather than repeating it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and artifacts ('Build a retention table and average curve from raw cohort counts'), which pins down the computation precisely. It also names the sibling it is not ('Not for a one-pass funnel (funnel_report)'), so the agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive condition ('Use when each cohort has counts per period since acquisition') and an explicit exclusion with a named alternative (funnel_report). Nothing about selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute the Pearson correlation between two numeric series. FREE.
Typical input {"x": [1, 2, 3, 4], "y": [2.1, 3.9, 6.2, 8.1]} returns {"pearson_r": 0.999, "r_squared": 0.998, "interpretation": "very strong positive correlation", "caution": "..."}.
Use when two equal-length numeric series may move together. Reports association only, never causation. Not for a single series over time (growth_rates). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need two equal-length series of 3+ values"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| x | Yes | First numeric series; at least 3 values, same length as y. | |
| y | Yes | Second numeric series; at least 3 values, same length as x. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered; the description adds genuine context beyond that with the error contract ('never raises a protocol error; returns {"error": ...}') and retry safety after correction. It does partially restate read-only/idempotency already in annotations, which keeps it from a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loads the core action and disambiguating example, with usage and error behavior following logically. Slight waste in the 'FREE.' fragment and a somewhat long error sentence, but overall tight.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 explained, yet the description still gives a sample response, plus the error path and the sibling exclusion. An agent has everything needed to call it correctly and handle failures.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both parameters are documented with length/type constraints, so the schema does the heavy lifting. The description only supplies an illustrative example array pair, adding format intuition but no constraints beyond what the schema already specifies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compute the Pearson correlation between two numeric series') plus a concrete input/output example, so the agent knows exactly what operation is performed. It also names the sibling it is not (growth_rates) for a single series over time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive condition ('Use when two equal-length numeric series may move together') and an explicit exclusion with the alternative tool to use instead ('Not for a single series over time (growth_rates)'). It also notes the association-only caveat, which shapes interpretation rather than invocation but reinforces correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Profile pasted CSV data column by column with data-quality flags. FREE.
Reports per-column type, null rate, unique count, numeric stats (min/mean/max), and top values. Typical input {"csv_text": "name,age\nAda,36\nLin,29"} returns {"rows": 2, "columns": {"age": {"type": "numeric", "null_pct": 0.0, "unique": 2, "min": 29, ...}}, "quality_flags": ["..."], "note": "first 2000 rows profiled"}.
Use as the first look at unfamiliar tabular data. Not for testing a hypothesis (ab_test, correlation) and not for time-ordered trends (growth_rates, forecast_trend). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "delimiter must be a single character, e.g. ',' or ';'"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| csv_text | Yes | Raw CSV content including a header row, pasted as a single string; the first 2000 data rows are profiled. | |
| delimiter | No | Field separator, exactly one character, e.g. "," or ";". Default ",". | , |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, and the description goes beyond them with two genuinely additive facts: the tool never raises a protocol error but returns {"error": ...}, and only the first 2000 rows are profiled. It also states retry-safety after correction, which is behavioral guidance no annotation field conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose is front-loaded in the first clause and the FREE marker is immediate. The inline example output is somewhat verbose and partially redundant with the output schema, but every sentence (usage, exclusions, error contract, retry safety) carries information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter read-only profiling tool with an output schema and full annotations, the description covers purpose, alternatives, error semantics, truncation limit, and retry safety. An agent could call and recover from failures correctly using this text alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3; the description earns an extra point by showing a concrete input string ({"csv_text": "name,age\nAda,36\nLin,29"}) that makes the 'paste raw CSV with header row' convention unambiguous. The delimiter error sample ('delimiter must be a single character') reinforces the one-character constraint, though most of this is restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Profile pasted CSV data column by column with data-quality flags', then enumerates exactly what it reports (type, null rate, unique count, min/mean/max, top values). The sibling-exclusion sentence ('Not for testing a hypothesis... not for time-ordered trends') lets an agent disambiguate from ab_test, correlation, growth_rates and forecast_trend without reading their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly prescribes the use case ('Use as the first look at unfamiliar tabular data') and names four sibling alternatives with the condition that excludes each. Both when-to-use and when-not-to-use are present, which is the top of the scale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Forecast future periods with a linear trend and honest fit quality. PREMIUM (license).
For quick planning, not statistical modeling. Typical input {"values": [100, 120, 138, 161], "periods_ahead": 3} returns {"trend_per_period": 20.2, "r_squared": 0.998, "forecast": [180.9, 201.1, 221.3], "caveat": "..."}.
Use when a series is roughly linear and fit quality matters as much as the projection. Not for seasonal or cyclical data, and not for measuring growth already observed (growth_rates). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need at least 4 historical values"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Ordered historical series, oldest first; at least 4 values. | |
| periods_ahead | No | How many future periods to forecast; values outside 1-12 are clamped. Default 3. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds genuinely new behavior: a premium license requirement, a non-protocol error contract ({"error": ...}) with an example message, and the retry-safety consequence of idempotency. Those are things an agent cannot infer from annotations or schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and licensing, then example, then usage boundaries and error contract. Every element earns its place, though the embedded JSON example is bulky and the read-only/idempotent sentence partially restates the annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values needn't be explained further, yet the example still grounds them. Combined with license gating, error semantics, minimum-input constraint, and exclusion rules, an agent has everything needed to call this correctly on the first try.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and both parameters are described there, so baseline would be 3. The worked example input/output goes beyond the schema by showing the concrete shape of the values array, what the returned trend and r_squared mean in practice, and that a caveat field accompanies the forecast.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("Forecast future periods with a linear trend") and immediately qualifies the output (fit quality). It also explicitly separates itself from growth_rates and from seasonal/cyclical use cases, so an agent can pick it over its siblings without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when: "a series is roughly linear and fit quality matters as much as the projection." Gives explicit when-not: seasonal or cyclical data, and measuring already-observed growth, naming the growth_rates alternative. Also flags the PREMIUM license gate up front.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a conversion funnel and find the biggest drop-off. PREMIUM (license).
Typical input {"stages": {"Visited": 1000, "Signed up": 200, "Paid": 50}} returns {"steps": [{"from": "Visited", "to": "Signed up", "conversion_pct": 20.0, "lost": 800}, ...], "overall_conversion_pct": 5.0, "biggest_dropoff": {...}, "recommendation": "..."}.
Use when stage counts descend through one funnel. Not for retention over time (cohort_retention) and not for two-variant comparisons (ab_test). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need at least 2 stages"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| stages | Yes | Ordered mapping of stage name to count, top of funnel first; at least 2 stages with non-negative numeric values, e.g. {"Visited": 1000, "Signed up": 200}. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the readOnly/idempotent annotations by disclosing a license gate (PREMIUM), an error contract (never raises a protocol error; returns {"error": ...} with a fix hint), and retry safety after correcting input. These are traits the annotations cannot express and they materially change how an agent handles failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, examples, usage rule, and error behavior are front-loaded and each section is short. The input/output example pair is somewhat verbose given an output schema already exists, but it is not wasted for a nested-object parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter analytic tool this covers everything an agent needs: what it computes, when to pick it, what the response contains, and how errors arrive. Return values are additionally backed by an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already documents ordering, minimum stage count, and value type, so the baseline is 3. The worked input example and the sample error ('need at least 2 stages') reinforce the shape and the descending-order constraint, adding modest value over the schema text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Analyze a conversion funnel') plus a second concrete outcome ('find the biggest drop-off'). It also explicitly distinguishes itself from cohort_retention and ab_test, so an agent can route without opening any schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit inclusion rule ('Use when stage counts descend through one funnel') and two named exclusions with the sibling that handles each case. Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Compute period-over-period growth and CAGR for a numeric series. FREE.
Typical input {"values": [1000, 1100, 1320]} returns {"period_over_period_pct": [10.0, 20.0], "total_change_pct": 32.0, "avg_growth_per_period_pct_cagr": 14.89}.
Use when one series is already in period order. Not for comparing two variants (ab_test) and not for projecting future periods (forecast_trend). Errors: on invalid, missing, or malformed input this tool never raises a protocol error; it returns {"error": ""} (for example {"error": "need at least 2 values"}). Every call is read-only and idempotent, so after correcting the input it is always safe to retry.
| Name | Required | Description | Default |
|---|---|---|---|
| values | Yes | Ordered numeric series, oldest first, at least 2 values, e.g. monthly revenue [1000, 1100, 1320]. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/non-destructive, but the description adds a genuinely non-obvious behavioral contract: this tool never raises a protocol error, it returns an {"error": ...} object, and retry after correction is always safe. That is exactly the kind of information annotations cannot convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Purpose, cost, example, and routing guidance are front-loaded and easy to scan. The closing error paragraph is slightly wordy (the retry-safety point could be one clause), but every sentence carries usable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists and annotations cover safety, so the description only needs to add ordering semantics, sibling routing, and failure behavior — all present. Nothing an agent needs to invoke this correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single parameter already documents 'oldest first, at least 2 values' with the same example the description uses. The description's example input/output pair helps confirm ordering semantics but largely restates structured data, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Compute period-over-period growth and CAGR') and names the exact input shape it operates on. It also explicitly distinguishes itself from the two nearest siblings, ab_test and forecast_trend, so an agent can route without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit positive condition ('when one series is already in period order') and two explicit exclusions with named alternatives ('not for comparing two variants (ab_test)', 'not for projecting (forecast_trend)'). This is textbook when/when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ab_testcohort_retentioncorrelationcsv_profileforecast_trendfunnel_reportgrowth_rates
Add one secure layer between your agents and this server.