Paste-your-data analytics: CSV profiling, A/B tests, correlation, growth. 4 of 7 free.
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 provide readOnlyHint, idempotentHint, and destructiveHint. The description reinforces these with 'Every call is read-only and idempotent' and adds extra behavioral context: the tool never raises a protocol error on bad input but returns an error object. This gives the agent a clear expectation of the tool's failure mode, which is beyond what annotations alone offer.
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 description is well-structured: a single-sentence purpose statement, a concise example, usage guidelines, error behavior, and a concluding note on idempotency. Every sentence adds useful information; there is no filler. The most critical information (purpose and when to use) appears first, fitting the front-loading principle.
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?
Given the tool's moderate complexity (statistical test with four integer parameters), the description is complete. It covers what the tool does, when to use it (and when not), error handling, and a sample output that illustrates the return fields (rate_pct, p_value, verdict, etc.). The presence of an output schema (per context signals) further reduces risk, but the description alone already paints a clear picture.
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?
The input schema has 100% description coverage, so each parameter is already documented. The description adds value by providing a typical input example (e.g., '{
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 clearly states the tool 'Run a two-proportion A/B significance test with a plain-language verdict.' This is a specific verb (Run) and resource (A/B significance test), with an explicit output characteristic (plain-language verdict). The example input/output further clarifies the goal, and the tool is distinct from sibling tools like cohort_retention or correlation.
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?
The description explicitly states when to use: 'Use when exactly two variants each have a trial count and a conversion count.' It also gives exclusion criteria: 'Not for continuous outcomes such as revenue per user, and not for three or more variants.' Additionally, it explains error-handling behavior ('returns {
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 readOnlyHint, idempotentHint, destructiveHint. The description adds the important behavioral detail that errors are never raised as protocol errors but returned as part of the response payload with a fix message. This is critical for agent handling and goes beyond annotation values.
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 description is concise (4 sentences) and front-loaded with the core purpose. Every sentence serves a distinct role: purpose, example, usage guidance, error behavior. No waste.
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?
Given the tool's simplicity (1 parameter, output schema exists, annotations cover safety), the description covers input format, output structure, usage constraints, error handling, and retry safety. Nothing essential is missing 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 coverage is 100%, so baseline is 3. The description provides an example input and output, reinforcing the schema's explanation of the counts array structure. However, it does not add new semantic information beyond what the schema already describes (e.g., index meaning, 24-cohort limit). The example is illustrative but not semantically novel.
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 clearly states the tool builds a retention table and average curve from raw cohort counts. It distinguishes itself from the sibling tool funnel_report by stating 'Not for a one-pass funnel (funnel_report)', making the purpose unambiguous.
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 says 'Use when each cohort has counts per period since acquisition' and provides an exclusion 'Not for a one-pass funnel (funnel_report)'. It also notes that errors are returned in-band and that retrying after correction is safe, giving clear usage context.
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 provide readOnlyHint=true and idempotentHint=true, and the description reinforces these by stating 'Every call is read-only and idempotent, so after correcting the input it is always safe to retry.' It also discloses error behavior: 'this tool never raises a protocol error — it returns {"error": "..."},' which is beyond what annotations convey. No contradictions with 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?
Every sentence serves a purpose: definition, example input/output, usage guidance, limitation (causation), error handling, and idempotency. The description is front-loaded with the core purpose and immediately provides a concrete example. It is comprehensive without any superfluous language.
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?
Given the tool's moderate complexity (two numeric arrays, statistical output), the description covers all essential aspects: purpose, input constraints (length, equality), output format (with interpretation and caution), error handling, and idempotency. The presence of an output schema is complemented by the example, so the return values are well explained.
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?
The input schema has 100% description coverage, describing both x and y with types, minItems, and constraints. The description adds a concrete example of typical input ({"x": [1,2,3,4], "y": [2.1,3.9,6.2,8.1]}), which demonstrates the expected JSON structure and helps an agent format parameters correctly. This example provides meaning beyond the schema's textual descriptions.
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 clearly states 'Compute the Pearson correlation between two numeric series,' which is a specific verb+resource pair. It also distinguishes itself from the sibling growth_rates by explicitly noting 'Not for a single series over time (growth_rates).'
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?
The description explicitly states when to use: 'Use when two equal-length numeric series may move together.' It also provides a clear exclusion: 'Not for a single series over time (growth_rates).' Additionally, it includes a cautionary note about association vs. causation, guiding appropriate interpretation.
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 provide readOnlyHint, idempotentHint, destructiveHint. The description adds concrete behavioral details: error handling returns error object, safe to retry, and the 2000-row limit. No contradiction.
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 description is concise, front-loaded with purpose and 'FREE'. Every sentence serves a clear purpose: example, usage guidance, error handling, safety. No unnecessary words.
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?
Given the tool's simplicity (2 params, output schema exists, rich annotations), the description covers all needed aspects: purpose, example output, when to use, error behavior, and safety. It is fully complete for agent decision-making.
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%, so baseline is 3. The description adds value by providing a typical input example, showing the output structure, and reinforcing the 2000-row limit. This elevates it beyond the schema alone.
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 clearly states the tool profiles pasted CSV data column by column with data-quality flags. It gives a concrete example and explicitly distinguishes from siblings by stating it is for first look at unfamiliar data, not for hypothesis testing (ab_test, correlation) or time trends (growth_rates, forecast_trend).
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?
The description explicitly says when to use ('first look at unfamiliar tabular data') and when not to use ('not for testing a hypothesis... not for time-ordered trends'). It also explains error handling behavior (returns error object, never protocol error) and that it is read-only and idempotent, making retry safe.
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 readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds substantial behavioral context beyond annotations: it explains the error handling policy ('never raises a protocol error — it returns a JSON error object'), confirms idempotency and safety to retry, and mentions the 'honest fit quality' and a caveat in the output. These details give the agent a realistic expectation of the tool's behavior.
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 description is concise and well-structured. It starts with the primary action, then mentions licensing, gives an example, provides usage guidelines, explains error handling, and concludes with the tool's safety properties. Every sentence earns its place; there is no redundant or vague language. The information is front-loaded and easy to scan.
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?
Given the tool's complexity (linear forecasting with fit quality), the description fully covers input, output, error behavior, usage context, and the trade-off against siblings. The existence of an output schema is complemented by a sample output in the description. Sibling tools are listed and one is explicitly referenced. The description leaves no significant gaps for an agent to guess about.
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%, but the description adds meaningful semantics beyond the schema: it provides a concrete typical input example showing how the parameters are used, and it reveals clamping behavior for periods_ahead ('values outside 1-12 are clamped') which is not documented in the schema. The example also implicitly demonstrates the required array structure for values, reinforcing the schema requirements.
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 opens with a specific verb-resource pair ('Forecast future periods with a linear trend') and distinguishes itself from siblings by explicitly naming growth_rates as the alternative for growth measurement. It also clarifies that it is not for seasonal or cyclical data, leaving no ambiguity about the tool's scope.
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?
The description provides direct when-to-use guidance ('Use when a series is roughly linear and fit quality matters') and clear when-not-to-use instructions ('Not for seasonal or cyclical data, and not for measuring growth already observed (growth_rates)'). It also includes a typical input example and explains error handling behavior, making it easy for an agent to decide whether to invoke this tool.
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?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description confirms idempotency and read-only behavior and adds valuable context about error handling: 'this tool never raises a protocol error — it returns {"error": ...}' and after correction it is always safe to retry. This additional error behavior disclosure goes beyond 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 description is concise yet complete, using a few sentences to cover purpose, usage, input example, output example, exclusions, error behavior, and idempotency. It is front-loaded and every sentence adds value.
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?
Given the tool's complexity (1 parameter with nested object, output schema present), the description sufficiently explains input format, output structure, error handling, and retry safety. Sibling tools are listed in context, and the description provides adequate differentiation.
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?
The schema has 100% coverage for the single parameter 'stages' with a good description. The description adds extra meaning by showing a typical input example and explaining the ordering requirement ('top of funnel first; at least 2 stages with non-negative numeric values'), which provides additional semantics beyond 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?
The description explicitly states 'Analyze a conversion funnel and find the biggest drop-off', which is a specific verb+resource. It also distinguishes from sibling tools by stating 'Not for retention over time (cohort_retention) and not for two-variant comparisons (ab_test)', ensuring no ambiguity.
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?
The description provides clear when-to-use guidance: 'Use when stage counts descend through one funnel', and explicit exclusions with named alternatives. It also mentions PREMIUM licensing as a constraint.
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?
The description clearly states the tool is 'read-only and idempotent' and reveals a crucial behavioral trait: instead of throwing protocol errors, it returns a structured error object with a fix message. The annotations already declare `readOnlyHint: true`, `idempotentHint: true`, and `destructiveHint: false`, so the bar for transparency is lower. The description goes beyond annotations by detailing the error-handling behavior and retry safety. No contradictions with annotations are present.
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 description is well-structured, front-loading the core purpose in the opening sentence. Every sentence contributes distinct value: purpose, example input/output, usage guidance, error handling, and idempotency assurance. No filler or repetition. It is highly efficient and earns every word.
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?
Given the tool's low complexity (single required parameter), the presence of a clear output schema, and rich annotations, the description is nearly complete. It provides an illustrative example, usage guidelines, sibling differentiation, and error behavior. The only slight gap is that it does not explicitly state the return type format (e.g., that it returns an object with specific keys) beyond the JSON example, but the output schema covers this. For a one-parameter tool, this is very complete.
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?
The input schema has perfect coverage (100%), with a detailed description for the `values` parameter ('Ordered numeric series, oldest first, at least 2 values'). The tool's description reinforces this with a concrete example. Since schema coverage is complete, the baseline is 3. The description adds an example but does not significantly expand on the semantics already present in 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?
The description clearly specifies the action ('Compute period-over-period growth and CAGR'), the target resource ('numeric series'), and the output format with an example. It distinguishes the tool from siblings by naming `ab_test` and `forecast_trend` and stating what it does not do ('Not for comparing two variants' and 'not for projecting future periods'), making the purpose highly specific and unambiguous.
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?
The description explicitly states when to use this tool ('Use when one series is already in period order') and explicitly when not to use it, naming two sibling alternatives (`ab_test` and `forecast_trend`) with different purposes. This provides clear context for selection and exclusion, meeting the highest standard for usage guidance.
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. Dates show when Glama detected each change.
ab_testcohort_retentioncorrelationcsv_profileforecast_trendfunnel_reportgrowth_ratesClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
The statistical analyst in your AI chat — validated, citable, re-runnable analysis of your data.
Privacy-first web analytics. Query pageviews, referrers, trends, and AI insights.
Privacy-first web analytics for AI agents: visitors, revenue, funnels, visitor profiles.
SaaS runway calculator (MRR growth vs churn), breakeven, burn multiple. Free MCP connector.
Add one secure layer between your agents and this server.
Each tool has a clearly distinct purpose: A/B testing, cohort retention, correlation, CSV profiling, trend forecasting, funnel analysis, and growth rates. There is no overlap or ambiguity between them.
All tool names follow a consistent lower_snake_case pattern with descriptive names (ab_test, cohort_retention, correlation, csv_profile, forecast_trend, funnel_report, growth_rates). The naming is uniform and predictable.
With 7 tools, the server is well-scoped for a data analysis toolkit. It covers a range of common tasks without being too sparse or overwhelming.
The set covers key analysis tasks (A/B test, correlation, cohort retention, funnel, growth, forecast, profiling). However, it lacks a tool for continuous hypothesis testing (e.g., t-test) and basic descriptive statistics, which are minor gaps for the domain.