RollCallWorks: 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 RollCallWorks 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 provided, so the description carries the burden of explaining behavior. It does disclose the exact informational content returned and implies a read-only, low-risk operation, but it does not explicitly state that no data is modified or describe any other behavioral characteristics like cost or latency.
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 with no wasted words. The most important information—what the tool returns—is front-loaded, and the usage hint is placed immediately after in a concise, actionable form.
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, the description fully covers what an agent needs to know: the exact pieces of schema information returned and the recommended invocation order relative to other tools.
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 input schema is fully complete and there is no parameter ambiguity. The description adds value by explaining what the returned result will contain, which compensates for the absence of an output 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 precisely states the tool's output: columns, which are numeric, row count, and provenance banner, all for a specific named dataset. It also names the tool's role ('Call this first to learn the schema'), making it clearly distinguishable from the sibling exploration 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 a clear context for use: call this first to learn the schema. It does not explicitly name alternatives or say when not to use it, but for a zero-parameter schema-introspection tool, the guidance is clear and 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 RollCallWorks 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?
No annotations are provided, and the description does not explicitly state whether the operation is read-only, idempotent, or has any side effects. While the nature of the action (returning rows) implies a safe read, the lack of explicit transparency about permissions or effects leaves 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 concise, consisting of a single sentence that packs all essential information without redundancy. It follows a clear structure: subject, action, and purpose, making it easy to parse and understand.
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 only two parameters, the description is largely complete. It explains the selection logic and output ordering. However, it assumes prior knowledge of the 'RollCallWorks' dataset name and does not specify the return format (e.g., full row objects vs. specific fields), which could be relevant for an agent.
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 only defines types and constraints for 'column' and 'values'. The description adds crucial meaning: it explains that 'column' refers to a field in the dataset, 'values' are the set of values to match with an OR condition, and the 'order given' determines the output row order. This goes 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 states the tool's function: it retrieves rows from a specified dataset where a given column matches any of the provided values, and arranges them in the order given. The phrase 'for X vs Y questions' explicitly identifies the intended use case, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers a general hint about when to use this tool ('for X vs Y questions') but does not explicitly contrast it with sibling tools such as dataset_row or dataset_search. An agent would need to infer that this tool is for comparing multiple rows rather than fetching a single row or searching based on arbitrary conditions.
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 RollCallWorks 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 disclosing behavior. It states the returned provenance fields and implies a read-only operation with no side effects, which is adequate for this simple tool.
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 wasted words. The key purpose is front-loaded, and the usage guidance is immediately actionable.
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, read-only provenance lookup, the description covers the returned content and the intended use case. Nothing essential is missing given the tool's simplicity.
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, so the baseline applies. The description adds meaningful context about what the tool returns, even though there is no parameter schema to elaborate on.
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 (RollCallWorks dataset provenance) and states the exact content: source, computation date, licence, and citation. It distinguishes itself from sibling dataset tools by focusing on attribution metadata.
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 second sentence, 'Read this to attribute a figure correctly,' gives a clear when-to-use instruction. It does not explicitly contrast with sibling tools, but the use case is unambiguous enough for an agent.
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 RollCallWorks 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 burden of behavioral disclosure. It does disclose case-insensitivity, which is a useful behavioral trait. However, it does not mention whether results are limited, ordered, or how errors are handled. For a read operation this is a moderate gap; the case-insensitivity disclosure earns a 3.
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 that states the core operation and the key behavioral nuance (case-insensitive). No wasted words; the structure is clear and immediately usable.
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 exact-match lookup with two parameters and no output schema, the description is reasonably complete. It explains the matching semantics and case-insensitivity. However, it does not clarify whether multiple rows or a single row is returned (the title says 'a row' but the description says 'rows'), nor does it address ordering or pagination. Given the lack of annotations and output schema, the description leaves some ambiguity about the return shape.
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 bare string parameters with no descriptions, so the description must clarify their meaning. It does: 'column' is the dataset column and 'value' is the exact value to match. This adds meaningful semantics beyond the schema, but it does not specify allowed values, formats, or any constraints beyond the minLength in the schema. It partially compensates for the 0% 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 returns rows from the RollCallWorks dataset filtered by exact column-value equality, and explicitly notes case-insensitivity. The title reinforces this as an exact-key lookup. This distinguishes it from sibling tools like dataset_search (which likely does fuzzy or broader matching) and dataset_top (which returns a sample), even though no sibling is named.
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 usage when exact, case-insensitive matching is needed, contrasting with a search tool. However, it does not explicitly state when to avoid this tool or name alternatives. The context is clear but lacks explicit exclusions or alternative routing, so it falls short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the RollCallWorks 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 must carry the full behavioral burden. It does disclose case-insensitivity and a result limit ('up to 50'), which are useful. However, it does not state whether this is a read-only operation (though search implies it), how results are ordered, what happens when no rows match, or whether pagination is possible. Given the simplicity of the tool, this is adequate but not comprehensive.
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 action (rows whose cells contain the query) and adds the key constraint (up to 50). No wasted words, and it is immediately clear what the tool does.
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 description covers the tool's purpose and basic behavior but lacks details about the output format. With no output schema, the agent does not know whether the tool returns full row objects, IDs, or some projection. It also does not mention ordering or error handling. For a simple search tool, this may be sufficient, but more detail on the return shape would improve 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?
Schema description coverage is 50%: the 'query' parameter is described ('text to look for in any cell'), but 'limit' has no schema description. The description's 'up to 50' indirectly hints at the limit parameter, but does not explicitly state that the 'limit' parameter controls it. Since the schema already has a maximum of 50, the description adds minimal value beyond confirming the cap. It does not explain default behavior or the meaning of 'limit' beyond its schema constraints.
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 verb (search), the resource (RollCallWorks dataset), and the specific condition (cells contain the query, case-insensitive). It distinguishes itself from siblings like dataset_row (likely fetches specific rows) and dataset_columns (lists columns) by focusing on cell-content matching.
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?
No guidance is provided about when to use this tool versus alternatives. It does not mention any sibling tools, exclusions, or conditions under which another tool (like dataset_stats or dataset_compare) would be more appropriate. The agent is left to infer usage from the name and description.
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 RollCallWorks 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 burden of behavioral disclosure. It adds non-obvious details: grouping commas and currency are handled, and non-numeric rows are excluded and counted. This meaningfully informs result interpretation beyond the title.
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 front-loads the output statistics and then adds edge-case handling details. There is no filler or redundant restating of the tool name or title.
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 one-parameter, read-only statistics tool, the description is nearly complete. It enumerates the returned values and key parsing/cleaning behaviors, though the meaning of 'excluded and counted' is slightly ambiguous and there is no explicit output shape.
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%, and the schema only says the 'column' parameter is a string. The description clarifies that the value must refer to a numeric column, which adds meaning, but it does not specify the expected identifier format, such as whether it must match dataset_columns names or be case-sensitive.
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 the tool's exact outputs (count, min, max, mean, median, sum) and clearly scopes it to a numeric column of the RollCallWorks dataset. This is a specific verb-plus-resource statement that distinguishes it from row-level or search 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?
It establishes clear context: use this when aggregate numeric statistics for a column are needed. It does not explicitly say when not to use it or name alternatives, but the sibling tools' purposes are distinct enough that this description provides adequate situational guidance.
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 RollCallWorks 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 burden of behavioral disclosure. It correctly conveys a read-only ranking operation and the ordering direction, but it does not disclose default limit behavior, tie-breaking, or what happens with a non-numeric column. These are meaningful gaps for a tool that returns a ranked subset.
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 one tight sentence that front-loads the core behavior and includes a helpful natural-language query ('which is the most/least X'). It is concise with no filler, though it sacrifices some useful detail for brevity.
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?
With no annotations and no output schema, the description must carry more context, but it only covers the basic purpose. Missing details include the optional limit parameter, the ascending parameter semantics, default ordering, return format, and guidance on which sibling tools to use instead. It is under-specified for a 3-parameter 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%, with only the 'ascending' parameter described in the schema. The tool description does not mention 'limit' or 'ascending' by name, adding little beyond 'highest (or lowest)' which loosely maps to the ascending flag. The required 'column' parameter is implied but not formally tied to 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 title explicitly says 'Rank rows by a numeric column', and the description clarifies 'The highest (or lowest) rows of the RollCallWorks dataset by a numeric column'. This clearly distinguishes it from siblings like dataset_row (single row), dataset_search (filtering), and dataset_stats (aggregates) by focusing on row ordering.
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 descriptive phrase 'which is the most/least X' implies when the tool is useful, but there is no explicit guidance on when to prefer this over alternatives, nor any exclusions. Sibling differentiation is left to the agent to infer.
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!
TimeCardBook: the site's own MCP server — dataset; every answer cites the site.
HeadcountDesk: the site's own MCP server — dataset; every answer cites the site.
Add one secure layer between your agents and this server.
Each tool targets a distinct operation (schema, provenance, exact lookup, fuzzy search, comparison, stats, top-N), but dataset_row, dataset_search, and dataset_compare all return matching rows and could be confused without careful reading of their filter semantics.
All tools share the dataset_ prefix and use clear lowercase snake_case names. The second part is sometimes a noun (columns, provenance, row) and sometimes a verb/search-style word, but the pattern is uniform and predictable.
Seven tools is a well-scoped size for a single-dataset querying server. Each tool covers a distinct query mode without bloat or redundancy.
The set covers schema discovery, provenance/citation, exact value lookup, substring search, comparisons, numeric statistics, and top/lowest ranking. For a read-only dataset MCP server this is a complete lifecycle with no obvious dead ends.