Tenantvo: 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 Tenantvo 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 carries the full burden. It discloses the exact content returned (columns, numeric indicators, row count, provenance banner), making the tool's behavior transparent. It does not mention side effects or error conditions, but for a read-only schema overview tool, this is adequate and adds meaningful value beyond the empty schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence front-loads the output contents, then immediately gives the usage directive. Every word earns its place; there is no filler or repetition. It is an exemplar of concise, high-density documentation.
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, no-output-schema tool whose purpose is to provide an initial schema overview, the description fully covers what an agent needs: what it returns and when to invoke it. There are no missing prerequisites, constraints, or return-format expectations that would leave an agent uncertain.
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 description coverage is 100% (empty properties). The baseline for zero-parameter tools is 4, and the description does not need to explain parameters. It adds no redundant parameter information, 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 states exactly what the tool returns: columns, numeric flags, row count, and provenance banner. It names the resource (Tenantvo dataset) and explicitly frames the tool as a schema-learning entry point. This clearly distinguishes it from siblings like dataset_provenance and dataset_stats, which focus on narrower aspects.
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 'Call this first to learn the schema' provides explicit when-to-use guidance, placing it as the initial step before other dataset tools. It does not name alternative tools or explicitly state when not to use it, but the directive is unambiguous and contextually sufficient.
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 Tenantvo 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 behavioral burden. It does disclose key behavior: rows are selected by matching any given value and are returned in the order of the provided values. It does not mention handling of missing values, case sensitivity, or response shape, which would add further 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 sentence with no filler. The core behavior is front-loaded, and the usage hint is appended as a brief clarifying aside.
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 read tool with no output schema or annotations, the description adequately explains selection criteria and output ordering. It could mention the result format more explicitly, but the title and 'rows' wording make the intent reasonably 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?
Schema description coverage is 0%, so the description must compensate. The description clarifies that 'column' names the field to match and 'values' are the allowed values to filter by, and adds the ordering semantics. It does not restate schema constraints like min/max items, but the core meaning of both parameters is clearly conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: select rows from the Tenantvo dataset where a column matches given values, and return them in the provided order. The 'X vs Y' phrasing implies comparison use, which distinguishes it from sibling tools like dataset_stats or dataset_top, though no sibling is named explicitly.
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 via 'for "X vs Y" questions', giving usage context. However, it does not explicitly contrast with alternatives such as dataset_row or dataset_search, nor does it state when not to use it.
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 Tenantvo 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns provenance metadata (source, date, licence, citation) but does not explicitly state it is read-only or non-mutating. While the nature of the tool implies no side effects, the lack of explicit disclosure keeps it at an adequate but not outstanding level.
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 that lists exactly what is provided and ends with a clear usage directive. Every word earns its place; there is no fluff or redundancy.
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 tool with no output schema and no annotations, the description covers the essential information: what data it returns and when to use it. It does not specify the exact return format, but the listed fields give a strong hint. The description is sufficient for an agent to call the tool correctly, though a more explicit return structure would make it fully 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 tool has zero parameters, so the baseline is 4 per the rubric. The description adds no parameter-specific information, but that is unnecessary because there are no parameters to document. The schema is trivially complete with 100% coverage.
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 provides the source, computed date, licence, and citation for the Tenantvo dataset, which is a specific and distinct purpose from its siblings (columns, compare, row, search, stats, top). The verb 'read' and the concrete list of metadata fields make it 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 gives a clear usage context: 'Read this to attribute a figure correctly.' It tells the agent when to use the tool (when attribution is needed) but does not explicitly mention alternatives or exclusions. This meets the 'clear context, no exclusions' level.
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 Tenantvo 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 burden of behavioral disclosure. It only reveals that matching is case-insensitive and exact, but does not mention the return format, behavior on zero matches, potential multiple matches, or any error conditions. For a read-only lookup, this is a significant gap—agents cannot predict what the response will look like or whether it might be empty.
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 that conveys the core purpose immediately. There is no extraneous information, and the key qualifier ('exactly', 'case-insensitive') is placed prominently. It is efficient and to the point.
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 string params, no output schema), the description is reasonably adequate. It covers the matching logic but omits details about the return shape (list vs. single row), pagination, or handling of no matches. Since there is no output schema to fill this gap, the description should have provided at least a hint about what the response contains. This is a noticeable, though not critical, omission for such a straightforward lookup 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 explain the parameters. It does so indirectly: 'a column' maps to the 'column' parameter and 'a value' maps to the 'value' parameter, clarifying their roles in the query. However, it does not provide examples, format constraints, or edge cases, so it only partially compensates for the lack of schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('look up a row') on a specific resource ('Tenantvo dataset') with a precise condition ('where a column equals a value exactly, case-insensitive'). It clearly differentiates from siblings like dataset_search (which implies broader search) and dataset_top (which implies ranking), making the tool's 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?
The description implies when to use this tool (when an exact, case-insensitive match is needed) but provides no explicit guidance on when not to use it or which sibling to choose instead. It lacks direct comparisons to dataset_search or other alternatives, leaving the agent to infer based on the phrase 'exactly'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Tenantvo 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 carries the full burden. It discloses case-insensitivity and the 50-row cap, which is useful. However, it does not specify result ordering, whether all columns are searched, or whether the operation is read-only (though it is likely inferred). It adds some behavioral context but not exhaustive 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?
A single sentence that is efficient and front-loaded with the core behavior, then adds key modifiers (case-insensitive, limit). No wasted 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?
For a simple search tool with two parameters and no output schema, the description covers what is needed: what it searches, the dataset, and the limit. Minor gaps exist (e.g., default limit behavior, whether all columns are searched), but for an agent to call it correctly, the essentials are present.
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 already describes 'query' as 'text to look for in any cell'. The description adds case-insensitivity for query, which is valuable. However, 'limit' has no schema description, and the tool description only repeats the cap ('up to 50') without explaining its default behavior or that it controls the number of rows returned. Given 50% schema coverage, the description partially compensates but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb (search) and resource (Tenantvo dataset), specifies that it returns rows whose cells match the query, and notes case-insensitivity and a limit. It is specific enough to distinguish from sibling tools like dataset_columns or dataset_stats.
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?
Usage context is implied: this tool is for finding rows by cell content. However, there is no explicit 'when to use this vs. alternatives' guidance, and it does not mention when to avoid it or mention sibling tools as alternatives.
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 Tenantvo 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?
No annotations are provided, so the description carries the full burden. It discloses that grouping commas and currency are handled, and non-numeric rows are excluded and counted, which adds behavioral context beyond the schema. However, it does not specify the output format or error behavior, leaving some 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, dense sentence that front-loads the list of statistics and includes important parsing details. Every phrase contributes, making it concise and well-structured.
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 lack of an output schema, the description should clarify the return format, such as a dictionary of statistics. It lists the stats but does not explicitly state the return structure or how the excluded count is represented. This is a notable gap for completeness.
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 one parameter 'column' with 0% description coverage. The description adds meaning by indicating it is a numeric column name from the Tenantvo dataset, but it does not elaborate on accepted formats or behavior for missing columns. It partially compensates 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 explicitly states the tool computes count, min, max, mean, median, and sum for a numeric column of a specific dataset. It also mentions handling of formatting and non-numeric rows, which distinguishes it from sibling tools like dataset_row or dataset_top. This is a clear, specific purpose.
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 (numeric column stats) but does not explicitly state when to use this tool versus alternatives like dataset_columns or dataset_row. It implies usage for summary statistics but lacks explicit guidance on when not to use it or which sibling to choose instead.
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 Tenantvo 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 provided, the description carries the full burden of disclosing behavior. It only mentions 'highest (or lowest) rows' and 'numeric column', but omits critical behavioral details such as default limit, sorting direction, pagination, or return format. The tool's mutation/read-only nature is also unclear, and the schema's limit and ascending properties are not addressed in the description.
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 concise sentence that front-loads the core purpose and includes a clarifying example. There is no unnecessary verbosity, and the structure is efficient and easy to parse.
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 tool with 3 parameters, no output schema, and no annotations, the description is insufficient. It omits important operational context such as default limit values, sorting semantics (e.g., what happens when ascending is not provided), and any assumptions about the column data type beyond 'numeric'. An agent would need to infer too much to call 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?
Schema description coverage is low (33% only for 'ascending'). The description adds a single piece of semantic meaning by stating the column must be numeric, which is not explicit in the schema. However, it does not explain the 'limit' parameter or the 'ascending' behavior beyond what the schema already states, so it fails to compensate for the low schema coverage.
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 ranks rows by a numeric column, using a specific verb ('rank') and a concrete resource (the Tenantvo dataset). It also includes an example query ('which is the most/least X') that makes the intent unambiguous and distinguishes it from sibling tools like dataset_search or dataset_stats.
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 no explicit guidance on when to use this tool versus alternatives. It implies a usage context ('which is the most/least X') but does not mention any sibling tools or conditions for choosing this over dataset_search or dataset_row. There is no exclusion 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.
The tools are mostly distinct: schema, provenance, exact lookup, substring search, comparison across values, summary statistics, and top/bottom queries each serve a different purpose. There is mild overlap among dataset_row, dataset_compare, and dataset_search since all return matching rows, but their match semantics are clearly described.
All tools share the dataset_ prefix and use short, consistent lowercase names: columns, compare, provenance, row, search, stats, top. The pattern is highly predictable and easy to navigate.
Seven tools is well-scoped for a single-dataset query server. Each tool covers a clear part of the query surface without redundancy or bloat.
For a read-only dataset access server, the surface is complete: schema discovery, provenance/attribution, exact row lookups, substring search, value comparison, summary statistics, and top/bottom ranking. There are no obvious dead ends for common dataset questions.