Upkeepvo: the site's own MCP server — dataset; every answer cites the site.
The columns, which of them are numeric, the row count and the provenance banner of the Upkeepvo dataset. Call this first to learn the schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry behavioral context. It states the returned metadata and implies a read-only schema inspection, but it does not explicitly say there are no side effects, how large the response is, or how the provenance banner relates to dataset_provenance.
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?
Two short sentences carry the full payload: the first front-loads all output contents, the second gives the action instruction. Every word earns its place and no structured information is repeated.
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 parameterless metadata tool with no output schema, the description covers what the agent gets and when to call it, which is sufficient for correct invocation. Minor gaps remain around the meaning of the provenance banner and the exact return format, but these are not blocking.
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 zero properties, so there are no parameters to disambiguate; the baseline for a parameterless tool is satisfied. The description needs no parameter-level detail and does not waste space on 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?
The description lists the concrete contents returned—columns, numeric flags, row count, and provenance banner—and explicitly frames the tool as the first schema-learning step for the Upkeepvo dataset. It lacks a direct action verb like 'returns', but the resource and scope are unmistakable and distinct from siblings.
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?
'Call this first to learn the schema' provides explicit sequencing guidance that orients the agent before using other dataset tools. It does not spell out when to prefer dataset_provenance or dataset_stats, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the Upkeepvo dataset whose column is any of the given values, in the order given — for "X vs Y" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | ||
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It does disclose two key traits: rows are ordered according to the input values order, and matching is an OR over the given values. However, it omits output format, no-match behavior, and error handling, leaving meaningful gaps.
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 a single efficient sentence that front-loads the core filtering and ordering behavior and ends with the use case. It is appropriately concise for a simple two-parameter tool, though the 'side by side' title and the actual return behavior are slightly misaligned.
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, no output schema, and no annotations, the description adequately explains what rows are returned, the ordering rule, and the intended use case. However, it leaves the result format and no-match behavior unspecified, which an agent may need to know for reliable 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 0%, but the description compensates by explaining that `column` is the attribute to filter on and `values` are the matching values whose order determines the row order. This adds essential meaning beyond the bare schema, though it does not restate constraints 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 states the tool returns rows from the Upkeepvo dataset filtered by a column matching any of the given values, preserving the given order. This differentiates it from siblings like dataset_row (single row) and dataset_search (general search), and the 'X vs Y' phrase signals its comparative intent.
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 phrase 'for "X vs Y" questions' provides a clear use case, but the description does not explicitly state when not to use this tool or when to prefer an alternative such as dataset_search or dataset_row. The intended usage is implied rather than fully specified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The source, the date it was computed, the licence and the citation for the Upkeepvo dataset. Read this to attribute a figure correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It lists the type of information returned, which is useful, but it does not disclose response format, error behavior, or whether the data is always available for any dataset.
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?
Two sentences with no filler. The first sentence names the delivered content, and the second states the concrete usage intent. Every word earns its place.
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 zero-parameter lookup, the description is nearly complete: it states what is returned and why to call it. The only gap is the lack of an output schema or a note on return shape, but this is minor for a simple provenance query.
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 tool has zero parameters, so there is no parameter semantics to document. The baseline of 4 applies because nothing is missing and the schema requires no clarification.
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 identifies the tool as providing source, computation date, licence, and citation for the Upkeepvo dataset. It is distinct from siblings like dataset_columns or dataset_row, though it lacks an explicit verb like 'retrieve'.
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 phrase 'Read this to attribute a figure correctly' tells the agent when to use this tool. It does not explicitly contrast it with alternatives, but no sibling serves the same provenance purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The rows of the Upkeepvo dataset where a column equals a value exactly (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It does reveal the important case-insensitive exact-match behavior, but it leaves ambiguity about whether one row or multiple matching rows are returned and does not describe the result shape. This is partial transparency.
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 a single compact sentence with no filler. It front-loads the core behavior and the case-insensitive qualifier, but the title and description are somewhat redundant with each other.
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?
The tool has no output schema and no annotations, so the description needs to explain return behavior. It fails to clarify whether the result is a single row or multiple rows, what fields are returned, or how many matches may result. The ambiguity between 'Look a row up' and 'The rows...' leaves a meaningful gap.
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 0%, so the description must clarify the parameters. It conveys that 'column' is the dataset column and 'value' is the value to match, which adds meaning beyond the bare parameter names. It does not list valid columns or provide format details, but the relationship is clear.
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 title and description clearly identify a row lookup operation by a column-value match. The phrase 'equals a value exactly (case-insensitive)' distinguishes it from siblings like dataset_search, though the description itself lacks an explicit verb such as 'returns'.
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 implies this is for exact, case-insensitive matches versus broader search behavior, but it does not explicitly state when to prefer this tool over dataset_search or when not to use it. Usage guidance is present but only by implication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Upkeepvo dataset whose cells contain the query (case-insensitive), up to 50.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | text to look for in any cell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It usefully discloses case-insensitive matching and the 50-row cap, but it does not explicitly state that this is a read-only operation, describe the result shape, or address edge cases like no matches or how rows are ordered.
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?
A single front-loaded sentence with no filler. Every element — dataset scope, matching semantics, case-insensitivity, and cap — earns its place.
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 low-complexity text-search tool, the description covers the essential call-semantics: what is searched, how matching works, and the result ceiling. Without an output schema, it does not specify the exact return fields, but the name and sibling context make 'rows' sufficiently clear.
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 only 50% because 'limit' lacks a description. The description adds the case-insensitivity nuance for 'query' and the 'up to 50' cap, but the cap merely restates the schema's maximum. It does not explain default behavior or what happens when more than 50 rows match.
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 ('search'), a concrete resource ('Rows of the Upkeepvo dataset'), and the exact matching semantics ('cells contain the query, case-insensitive'). The behavior is distinct from siblings like dataset_row or dataset_stats, so an agent can tell this is a full-cell-match search tool.
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 implies the use case: find rows containing arbitrary text across any cell. However, it does not explicitly mention when to prefer this over siblings or when not to use it, leaving the agent to infer routing from the tool's name and behavior.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
count, min, max, mean, median and sum of a numeric column of the Upkeepvo dataset (grouping commas and currency are handled; non-numeric rows are excluded and counted).
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently explains that non-numeric rows are excluded and counted, and that currency and grouping commas are handled. This goes beyond what the schema alone would tell the agent. It does not mention error handling or return format, but the read-only nature of a stats tool is reasonably inferred.
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 a single, well-structured sentence that front-loads the list of statistics, then adds important handling details. There is no fluff or repetition. It efficiently communicates the core purpose and key behavioral nuances. Slightly more detail on parameter syntax would be welcome, but overall it is concise and organized.
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 simple tool with one parameter and no output schema, the description covers the essential aspects: what statistics are computed, how the data is cleaned (commas, currency, non-numeric exclusion), and the fact it targets a numeric column. It does not specify the exact return format (e.g., JSON object) or error handling, but given the simplicity, the description is fairly complete. An agent can likely invoke it correctly with the given information.
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 a single required parameter 'column' with no description, so schema coverage is 0%. The tool description adds meaning by specifying that the column must be numeric, which helps the agent choose an appropriate column. However, it does not elaborate on the format or constraints of the column value (e.g., must be a string column name). The description partially compensates for the missing schema descriptions but could be more explicit.
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 computes summary statistics (count, min, max, mean, median, sum) for a numeric column of the Upkeepvo dataset. It uses a specific verb ('computes' implied) and names the exact resource, distinguishing it from siblings that deal with columns, rows, search, etc. The list of statistics leaves no ambiguity about what the tool does.
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 context about how data is handled (grouping commas, currency, excluding non-numeric rows) but does not explicitly state when to use this tool versus alternatives like dataset_top or dataset_search. It implies usage for numeric column statistics but lacks explicit guidance or exclusions. No sibling alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The highest (or lowest) rows of the Upkeepvo dataset by a numeric column — "which is the most/least X".
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| column | Yes | ||
| ascending | No | true for the lowest first; default highest first |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full behavioral burden. It discloses the core ranking behavior and numeric-column requirement, but it does not mention default sort direction, limit handling, tie-breaking, or the output shape, leaving some ambiguity.
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 very short and front-loaded with the key concept. It avoids filler, though it is slightly under-specified rather than being a model of efficient completeness.
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?
There is no output schema and no annotations, so the description alone must fully equip an agent. It fails to clarify default values, limit semantics, or what the returned rows look like, which are meaningful gaps for a ranking tool.
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 only 33%, and the description adds meaning mostly by calling out that the column must be numeric and that results can be highest or lowest. It does not explain the limit parameter at all, which is central to how many rows are returned.
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 communicates ranking rows by a numeric column to find the highest or lowest values, which distinguishes it from sibling search/stat/compare tools. It does not explicitly name a sibling but the 'most/least X' phrasing gives a specific query intent.
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 'which is the most/least X' phrase implies the intended use case, and the sibling list helps an agent infer alternatives. However, the description does not explicitly state when not to use this tool or which sibling should be chosen instead.
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.
dataset_columnsdataset_comparedataset_provenancedataset_rowdataset_searchdataset_statsdataset_topClaiming 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!
Add one secure layer between your agents and this server.
Each tool has a distinct purpose: schema discovery, comparison, provenance, exact row lookup, substring search, stats, and ranking. No two tools overlap in functionality, making misselection unlikely.
All tools follow the consistent pattern 'dataset_' followed by a lowercase noun or verb (columns, compare, provenance, row, search, stats, top). The naming is uniform and predictable.
With 7 tools, the set is well-scoped for a dataset querying server. Each tool covers a distinct query need without redundancy or bloat.
The tools provide comprehensive read-only access to the dataset: schema, row retrieval, search, statistics, ranking, comparisons, and provenance. No obvious gaps for typical analysis workflows.