Duesvo: 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 Duesvo 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?
With no annotations provided, the description correctly carries the disclosure burden by enumerating the returned information: columns, numeric columns, row count, and provenance banner. It does not describe side effects, error behavior, or whether the operation is read-only, but for a schema-discovery call this is a reasonably clear behavioral picture.
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 two short sentences with no filler. The key output details are front-loaded, and the usage guidance is a separate, direct call to action. 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?
This is a simple zero-parameter tool with no output schema, so the description must communicate return value substance on its own. It lists the main return elements, which is sufficient for an agent to know what to expect. It could add a bit more about the format of the provenance banner, but overall the context is complete enough.
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 the baseline is 4. The description does not need to document parameter meaning; instead, it focuses on what the tool returns, which is appropriate.
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 what the tool provides: the columns, numeric flags, row count, and provenance banner of the Duesvo dataset. It is distinct enough from siblings like dataset_provenance and dataset_stats because it returns schema-focused structural information, though it does not explicitly name and contrast sibling tools.
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 instruction 'Call this first to learn the schema' gives clear context for when the tool should be used as an initial discovery step. It does not explicitly mention alternatives or exclusions, but the guidance is direct enough for an agent to decide.
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 Duesvo 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 carries the full burden. It discloses two behavioral traits: filtering by column values and preserving the order of the values. However, it does not mention exact-match semantics, case sensitivity, handling of missing values, or whether the full rows are returned. This is partial transparency for a read-only operation.
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, focused sentence that states the core function and the specific use case. No wasted words; it is front-loaded with the operation and includes the key ordering behavior.
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, two-parameter retrieval tool, the description is mostly complete. It explains what rows are returned and in what order. It lacks explicit notes on edge cases or output shape, but those are less critical given the straightforward nature and the absence of an output schema is partially mitigated by the phrase 'rows side by side'.
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 compensate. It explains the relationship between 'column' and the 'given values' and adds that output order follows the values array. It does not explicitly name the parameters or describe constraints, but the simple schema already provides clear property names and types, so the added value is moderate.
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's function: retrieving rows from the Duesvo dataset where the specified column matches any of the given values, preserving the given order. The 'X vs Y' phrasing helps differentiate it from sibling tools like dataset_row or dataset_top, though the exact comparison presentation is not detailed.
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 states the intended use case ('for X vs Y questions'), giving clear context for when to choose this tool. It does not explicitly name alternatives or exclusions, but the scenario is specific enough that an agent can infer its niche among siblings.
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 Duesvo 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 burden of behavioral disclosure. It implies a read-only operation through 'Read this' and lists what the user will find, but it does not explicitly state that the tool has no side effects, whether it requires special access, or what format the provenance information takes. The description is adequate but leaves some behavioral details implicit.
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 convey the resource, the fields returned, and the intended use case with no filler or redundancy. The key content is front-loaded and every clause 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?
For a simple zero-parameter provenance tool, the description is complete: it names the dataset, enumerates the returned attributes (source, date, licence, citation), and explains why the agent would invoke it. No output schema exists, but the listed fields provide sufficient expectation for the response.
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 and the schema coverage is 100%, so there is no parameter meaning to add. The description appropriately focuses on what the tool returns rather than parameter details, matching the baseline for param-free tools.
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 resource (the Duesvo dataset) and the information returned (source, computed date, licence, citation). It lacks an explicit verb like 'returns' or 'gets', but 'The source...' plus 'Read this to attribute a figure correctly' makes the purpose unambiguous and distinguishes it from sibling dataset analysis tools.
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' gives a clear context for when this tool should be used. No exclusions or alternative tool comparisons are provided, but for a zero-parameter provenance metadata tool, this level of guidance is adequate.
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 Duesvo 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 full behavioral burden and does disclose a key non-obvious trait: the match is case-insensitive. It does not disclose whether multiple matching rows are returned, what the output shape is, or what happens on no match, leaving some important behavior 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, front-loaded sentence with no filler. It states the resource, the operation, and the matching rule efficiently without repeating what the title or schema already show.
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 two-parameter lookup tool, the description gives the core semantics but relies heavily on inference. There is no output schema, no annotations, and no mention of return shape, cardinality, or match failure behavior, so an agent must guess several practical details before confidently invoking the 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 0%, so the description must compensate. It does map the two parameters into a semantic relationship: rows where a column equals a value. It does not explain column naming conventions, accepted value formats, or how to reference columns, but the parameter names and the equational phrasing provide enough basic guidance.
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 states a clear verb and resource ('Look a row up by an exact key'), and the description identifies the Duesvo dataset and exact equality matching. It differentiates from dataset_search through the word 'exactly', though it does not name the sibling explicitly. Minor grammar ambiguity ('where a column equals a value') and singular 'row' vs plural 'rows' slightly reduce clarity.
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 tool should be used for exact-match lookups on a specific column/value pair. However, it does not state when to prefer dataset_search or another sibling, nor does it give any exclusions or alternative conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Duesvo 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?
With no annotations provided, the description carries the behavioral burden itself. It discloses that the match is case-insensitive, that any cell can match, and that results are capped at 50. It does not describe output shape or ordering, but the key operational traits of this search tool 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?
A single, compact sentence with no filler. The core behavior is front-loaded and the two modifiers ('case-insensitive', 'up to 50') are high-value constraints that an agent needs before calling the tool.
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 two-parameter search tool, the description covers matching behavior, case sensitivity, and the result cap. It does not provide an output schema or detail the exact return structure, but 'Rows' plus the simple domain gives an agent enough to invoke it correctly.
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 query parameter is described in the schema and the description adds the case-insensitive matching behavior. However, the limit parameter has no schema description, and while 'up to 50' hints at a cap, it does not explicitly clarify that limit controls the number of returned rows or what the default behavior is.
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 names a specific behavior: returning rows of the Duesvo dataset whose cells contain the query. It also adds precise details (case-insensitive, up to 50 results) that separate it from sibling tools like dataset_columns, dataset_stats, and dataset_top.
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 tool is for substring-based cell search, so an agent can infer the basic use case. However, it does not explicitly say when to choose this tool over dataset_row, dataset_top, or other siblings, nor does it state any exclusions or alternative conditions.
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 Duesvo 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 behavioral disclosure burden. It goes beyond the title by explaining that grouping commas and currency symbols are handled and that non-numeric rows are excluded and counted, which is valuable edge-case behavior for an agent to know.
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 dense sentence with no filler. The statistic list is front-loaded, and the edge-case handling is compactly placed in a parenthetical.
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 tool with no output schema, the description is complete: it names the input (numeric column), the output values (count, min, max, mean, median, sum), and the handling of non-numeric rows. No critical missing context prevents 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 0%, so the description must compensate for the single 'column' parameter. It does this meaningfully by clarifying that the column must be numeric and that formatting like commas and currency is tolerated, adding practical semantics beyond the bare string field.
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 names a specific verb-resource pair (computes summary statistics for a numeric column of the Duesvo dataset) and enumerates the exact statistics returned. This clearly differentiates it from sibling tools like dataset_search, dataset_compare, or dataset_columns.
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 when to use the tool, namely when numeric summary statistics are needed for a column. However, it does not explicitly state when not to use it or name alternative tools, so usage guidance is mostly inferred rather than direct.
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 Duesvo 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?
With no annotations, the description carries the full burden of disclosing behavior. It does state the core behavior: sorting/filtering rows by a numeric column in ascending or descending order. But it does not disclose tie-handling, nulls, invalid column types, whether full rows are returned, or any default limit 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 a single compact sentence with no filler, and the 'most/least X' phrase adds interpretive value. It could be slightly clearer, but it earns a good score for efficiency and front-loading the core purpose.
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 compensate. It leaves important operational details unspecified: the default limit, the shape of returned rows, sorting behavior for ties or non-numeric data, and how the result relates to the rest of the Duesvo dataset. This is enough to make a call, but not enough for confident invocation without additional inference.
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%, with only the 'ascending' parameter described. The description adds useful meaning for 'column' by saying it must be numeric, and it clarifies ascending/descending intent via 'highest (or lowest)'. However, it adds no semantics for 'limit', including what the default is or how it affects results.
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 that the tool ranks rows by a numeric column and returns the highest or lowest rows, using the phrasing 'which is the most/least X' to make the intent understandable. It distinguishes itself from generic row retrieval or statistics tools, though it does not explicitly contrast with any sibling.
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 intended use is implied through 'highest (or lowest)' and 'most/least X', so an agent can infer when a ranking question is being asked. However, there is no explicit guidance about when to choose dataset_top over siblings such as dataset_stats, dataset_row, or dataset_search, and no exclusions or alternative routing.
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.
Most tools have clearly distinct purposes: schema, provenance, exact match, substring search, multi-value comparison, aggregate stats, and top/bottom ranking. The minor overlap between dataset_row, dataset_search, and dataset_compare could cause occasional misselection, but each description states its exact matching behavior.
All tools share the dataset_ prefix, which creates a strong family resemblance. However, the suffix is sometimes a noun (columns, provenance, row) and sometimes a verb (compare, search, stats, top), so the pattern is not fully uniform.
Seven tools is a well-scoped set for querying a single dataset. Each tool addresses a distinct common question type without redundancy or bloat.
The set covers schema discovery, provenance, exact lookups, fuzzy search, controlled comparison, numeric aggregates, and sorted extremes. A general arbitrary filter or grouped analysis is missing, but the provided tools handle the most likely dataset questions.