TimeCardBook: 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 TimeCardBook 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?
Without annotations, the description carries full transparency burden. It enumerates exactly what information will be returned (columns, numeric flags, row count, provenance banner), giving a clear expectation of the tool's output and side-effect-free nature. It does not mention any destructive or state-changing behavior, which aligns with a read-only schema inspection.
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 that contains all essential information without fluff. It is well-structured and immediately readable.
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 no parameters and no output schema, the description fully covers what the agent needs to know: what data it returns and when to call it. The instruction to call first adds context that helps orchestrate with other dataset tools. No critical information is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (i.e., nothing to document). The description adds no parameter-specific semantics because there are none. This is the baseline score for a no-parameter tool.
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 columns, numeric flags, row count, and provenance banner for a specific dataset, and explicitly instructs to call it first to learn the schema. This unambiguously separates 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?
It provides a direct usage directive: 'Call this first to learn the schema.' This tells the agent when to invoke it, though it does not explicitly contrast with alternatives. Still, the guidance is clear and actionable.
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 TimeCardBook 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 useful traits: rows are ordered by the given value order and matching is by 'any of' the values. It does not mention output format, case sensitivity, exact-match semantics, or behavior when no rows match.
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, and the core filtering behavior is front-loaded. The syntax is slightly awkward (a noun phrase rather than an explicit imperative), but it remains compact and efficient.
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 with no output schema, the description states what is returned (rows selected by column values) and the ordering, which is the key context. It does not detail row shape or edge cases, but those are likely discoverable via sibling tools like dataset_columns.
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 is the only source of parameter meaning. It explains that 'column' is the field to match against and 'values' are the accepted values, and that their order drives the output row order—adding real semantics beyond the raw 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 identifies the TimeCardBook dataset and the row-selection behavior (column matching any of the given values, in given order), and the title supplies the 'compare' verb. It distinguishes this tool from siblings by specifying value-based row selection for comparison, though it lacks a direct main verb like '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 phrase 'for X vs Y questions' gives a clear use case for side-by-side comparison, and the ordering detail implies the intended comparison workflow. However, it does not explicitly name alternatives or state when not to use this tool.
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 TimeCardBook 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 implies a read-only, informational tool, but does not explicitly state that it has no side effects or that it requires no special permissions. Adequate but not rich.
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, direct sentences with no filler. The primary message (what the tool provides) is front-loaded, and the use case is given in the second sentence.
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 absence of parameters and output schema, the description is sufficient to understand the tool's purpose and expected return value. It could have mentioned that it is metadata-only, but that is not necessary for a clear understanding.
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?
There are no parameters, and the schema coverage is 100% (empty schema). The description explains what the tool returns (source, date, licence, citation), so there is nothing missing in parameter 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 description states a specific verb ('read this to attribute') and a specific resource ('TimeCardBook dataset'), and clearly differentiates from siblings by focusing on provenance (source, date, licence, citation) rather than data content or 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?
Explicitly tells when to use it ('Read this to attribute a figure correctly'), giving a clear use case. It does not explicitly contrast with alternatives, but the context and dataset name make the purpose obvious.
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 TimeCardBook 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?
No annotations are provided, so the description carries the full burden. It states what the tool returns (rows) and the matching behavior, but it does not explicitly mention whether it is read-only, whether it returns all matches or just the first, or how errors are handled. This leaves some behavioral 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 a single, well-structured sentence that conveys the essential information without unnecessary detail. 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?
For a simple lookup tool, the description is sufficiently complete: it names the dataset, the matching condition, and the result type (rows). It does not specify ordering, limits, or the exact shape of the returned rows, but these are likely secondary for a direct lookup operation.
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 description explains both parameters: 'column' is the field to match and 'value' is the exact value to look for. Since the schema has no parameter descriptions, this coverage is helpful. However, it does not specify allowed column names or value formats, which could be relevant in practice.
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 returns rows from the TimeCardBook dataset where a column matches a value exactly (case-insensitive). This is a specific verb ('look up') and resource ('TimeCardBook dataset'), and it distinguishes the tool from siblings like dataset_columns (which returns columns) and dataset_stats (which returns statistics).
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 defines the matching condition (exact, case-insensitive) but does not explicitly contrast with alternatives like dataset_search. There is no direct guidance on when to use this tool versus dataset_search or other siblings, leaving the choice to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the TimeCardBook 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, the description bears the full burden. It reveals case-insensitivity and a limit of 50, but omits behavior for empty results, default values, or error handling. Adequate but not exhaustive.
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, tightly worded with no redundant content. It directly conveys the essential behavior and constraints.
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, the description is sufficient. It specifies the search scope, matching behavior, and result limit. No output schema exists, but the tool's purpose is clear enough without detailing return structure.
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 description adds meaning to query (case-insensitive) and limit (up to 50) beyond the schema's constraints. Query's schema description is minimal, but the description clarifies semantics. Limit has no description but the description supplies its practical meaning.
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 returns rows containing the query, distinguishing it from sibling tools like dataset_stats or dataset_columns. The verb 'search' is implicit but the function is 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 (searching content), but does not explicitly mention alternatives or when-not-to-use. Sibling names suggest distinct purposes, yet no direct comparison is given.
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 TimeCardBook 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?
The description adds useful behavioral details beyond the bare title, noting that grouping commas and currency symbols are handled and that non-numeric rows are excluded and counted. This informs the user about data cleaning behavior, though it could be more explicit about the output format or error handling.
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 packs in the statistics computed and the key behavioral caveats. There is no fluff or redundant wording; every clause adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description covers the core functionality and important edge-case behavior. It could mention whether the tool returns a single row or separate values, and whether it supports multiple columns, but overall it is sufficient for basic understanding.
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 provides only a 'column' parameter with no description. The description indicates the column should be numeric, which adds some meaning, but it does not clarify whether the column name must match exactly, case sensitivity, or how to reference columns with special characters. Given the 0% schema coverage, more parameter detail would be valuable.
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 lists the exact statistics computed (count, min, max, mean, median, sum) and identifies the resource as a numeric column of the TimeCardBook dataset. This is a specific verb+resource pairing that clearly distinguishes the tool from general data 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 description gives no guidance on when to use this tool versus sibling tools like dataset_top, dataset_row, or dataset_search. It does not mention appropriate use cases or conditions that would make this tool the preferred choice.
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 TimeCardBook 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 must convey behavior. It explains that rows are returned ordered by highest or lowest values, but does not mention default limit behavior, tie handling, or whether the full row is returned. The schema only documents the ascending parameter, leaving these details unspecified.
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, immediately front-loading the core action and supporting phrase. No unnecessary words 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?
The tool is simple and has no output schema; the description adequately conveys that rows are returned for the top/bottom by a numeric column. It lacks explicit mention of default limit and output shape, but these are minor gaps given the tool's straightforward nature.
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 (only 33% for ascending). The description compensates by indicating that 'column' must be numeric and implying that ascending relates to lowest ordering, but it adds no meaning for the 'limit' parameter, whose semantics remain undocumented.
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 and returns the highest or lowest rows, directly addressing 'most/least X' questions. The title reinforces this by naming the action 'Rank rows by a numeric column'.
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 includes a natural-language use case ('which is the most/least X') that helps an agent know when to invoke this tool. It does not explicitly contrast with sibling tools, but the ranking-specific language is sufficient for selecting it over search/statistics tools in most cases.
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!
HeadcountDesk: the site's own MCP server — dataset; every answer cites the site.
EmployeeDeskHQ: the site's own MCP server — dataset; every answer cites the site.
RollCallWorks: the site's own MCP server — dataset; every answer cites the site.
RunbookDesk: the site's own MCP server — dataset; every answer cites the site.
Add one secure layer between your agents and this server.
Each tool addresses a distinct query pattern: schema discovery, provenance, exact-match lookup, substring search, ordered multi-value comparison, column statistics, and top/bottom row ranking. The only close pair is dataset_row and dataset_compare, but their descriptions clearly separate exact single-value equality from ordered value-list comparison.
All seven tools use the same dataset_ prefix and snake_case convention, producing a predictable and scannable set. Although suffixes mix nouns (columns, stats) and verbs (compare, search), the consistent prefix and clear semantic labels make naming highly regular.
Seven tools is well-scoped for read-only interrogation of a single dataset, covering metadata, lookup, search, comparison, statistics, and extreme values without redundancy. The count is comfortably in the ideal range for this purpose.
The surface covers the main dataset operations: schema, provenance, exact and fuzzy retrieval, comparisons, aggregates, and ranking. A minor gap is the lack of a way to retrieve all rows or list unique categorical values, but most realistic questions can be answered with the provided patterns.
