Runsheetly: 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 Runsheetly dataset. Call this first to learn the schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden for behavioral disclosure. It does not explicitly state read-only behavior or absence of side effects, though the schema-inspection nature strongly implies no mutations. A score of 3 reflects this missing explicit safety disclosure.
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 sentences, front-loading the primary return components (columns, numeric flags, row count, provenance banner) before the usage directive. There is no redundancy, and every word 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?
With no output schema, the description compensates by listing all expected return components: columns, numeric indicators, row count, and provenance banner. This is sufficient for an agent to anticipate the result, though the provenance banner's structure remains underspecified.
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, making schema coverage trivially 100%. No parameter-specific detail in the description is needed, so the baseline 4 applies without adjustment.
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 a provenance banner for the Runsheetly dataset, reinforced by the directive 'Call this first to learn the schema' and the title 'Dataset columns and shape.' The return components are enumerated, though the exact output format is not fully specified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
'Call this first to learn the schema' provides explicit when-to-use guidance, implying it should precede other dataset operations. While it does not enumerate sibling tools, the directive gives adequate routing context to distinguish it from tools like dataset_row or dataset_stats.
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 Runsheetly 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 present, so the description carries the full burden. It usefully discloses that rows are filtered by column values and returned in the order the values are given. It does not, however, describe exact-match semantics, output shape, or how the comparisons are rendered, leaving some behavior 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 entire description is one tight sentence with no redundant wording. It front-loads the core behavior and appends only the relevant use-case hint. Every part contributes to understanding 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?
There is no output schema or annotation, and the description omits the return format, error behavior, and matching semantics. For a simple two-parameter tool this is partially compensated by the clear filter+order description, but an agent still does not know what 'compare rows side by side' actually returns.
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 link 'column' and 'values' to their roles ('whose column is any of the given values') and adds the ordering behavior. Yet it does not clarify whether values must be exact strings, how column names are resolved, or any formatting requirements beyond the 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 states a specific operation: returning rows whose column matches any of the supplied values, preserving the given order. It also frames the use case as 'X vs Y' questions, which helps distinguish it from generic dataset search or single-row retrieval, though it does not explicitly name a sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'for "X vs Y" questions' gives a clear intended context, implying comparison between specific values. However, it does not explicitly state when to avoid this tool or mention alternatives like dataset_search or dataset_row, so usage guidance is implied rather than explicit.
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 Runsheetly 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 full burden. It discloses the content returned (source, date, licence, citation) and the purpose, but doesn't specify the format (e.g., text, structured fields) or any side effects. For a read-only metadata tool, this is sufficient transparency, though it could mention that it returns a summary or text block.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no fluff. The first sentence lists exactly what the tool provides, and the second gives the usage context. The most important info is front-loaded, making it efficient for an agent 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 no parameters and no output schema, the description is complete enough. It tells the agent what it will get and why to use it. The only minor gap is not specifying the return format, but for a provenance tool this is not critical.
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 is empty with 100% coverage, so there is nothing to explain. Baseline for 0 parameters is 4, and the description adds no parameter details because none exist.
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 provenance metadata: source, computation date, licence, and citation for the Runsheetly dataset. This is distinct from sibling tools like dataset_columns (structure) or dataset_stats (aggregates), so an agent can immediately tell it apart.
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 explicitly says 'Read this to attribute a figure correctly,' giving a precise scenario for when to use it. It implies this tool is for citation/attribution purposes, which is a clear use case distinct from data exploration or manipulation.
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 Runsheetly dataset where a column equals a value exactly (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses the case-insensitive matching behavior, which is valuable, but omits details such as whether all matching rows are returned or only the first, what happens with no matches, and the return format. It adds some context but is 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, focused sentence with no redundant words. The core matching rule is front-loaded, making it easy to parse quickly. It is concise without sacrificing essential 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?
Given the absence of an output schema and annotations, the description should fully enable correct invocation. It explains the operation and the matching rule, but does not specify the return cardinality, error behavior, or what the output looks like. These gaps make it incomplete for an agent that needs to handle results, though the core operation is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. It mentions 'a column' and 'a value' in relation, implying their roles, but does not explicitly define them as the column name and the exact value to match. The case-insensitive note applies to the value matching, but parameter semantics remain under-explained for an agent with no other context.
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 indicates the tool retrieves rows from the Runsheetly dataset that match an exact, case-insensitive column value. It distinguishes from siblings like dataset_search (likely fuzzy) and dataset_top, though the title says 'a row' while the description says 'rows', introducing minor ambiguity about cardinality.
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 given on when to prefer this tool over its siblings, such as dataset_search for fuzzy matching or dataset_top for aggregated views. The description neither states conditions for use nor mentions alternatives, leaving the agent to infer the appropriate choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Runsheetly 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 carries the full burden. It discloses case-insensitivity and a 50-row cap, but does not explain the return format, default limit behavior, or what happens when no matches are found. This is moderate transparency for a search 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 a single, front-loaded sentence with no redundant words. It efficiently conveys the core purpose and key constraints, making it easy to parse quickly.
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 simplicity of the tool and lack of output schema, the description covers the essentials (search behavior, case-insensitivity, cap). However, it omits usage guidance relative to siblings and does not clarify whether the limit is a default or required parameter, leaving some ambiguity 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 provides a description for 'query' but not for 'limit'. The description's mention of 'up to 50' adds context for the limit parameter and clarifies the search scope across all cells, partially compensating for the 50% 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 searches rows of the Runsheetly dataset for cells containing the query, case-insensitive, with a limit of 50. It names the specific resource and behavior, effectively distinguishing it from sibling tools like dataset_stats or dataset_row which serve different purposes.
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 given on when to use this tool versus the sibling tools (e.g., dataset_columns, dataset_compare). The description does not mention any exclusions or alternative tools, leaving the agent to infer usage from the tool name alone.
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 Runsheetly 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, the description carries the full burden of behavioral disclosure. It honestly discloses that grouping commas and currency symbols are handled and that non-numeric rows are excluded and counted, which are meaningful edge-case behaviors an agent needs to know. It does not describe the exact response shape, but the computed stats themselves are listed.
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 result set and then adds the important caveats. Every element earns its place, and there is no redundant or vague filler.
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 tool, the description covers the tool's purpose, the parameter's semantic constraint, and the data-handling behavior. It would be slightly stronger with an explicit note about output structure or error behavior, but nothing essential for choosing and invoking the tool 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?
Schema coverage is 0%, so the description must compensate. It adds the key semantic that the column must be numeric and that non-numeric values are excluded, but it does not explain how the column name should be specified, whether it must match dataset_columns exactly, or what happens if the column does not exist.
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 resource (numeric column of the Runsheetly dataset) and enumerates the exact aggregates computed (count, min, max, mean, median, sum). It clearly distinguishes the tool from sibling tools like dataset_top or dataset_search, which serve different lookup/aggregation purposes.
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 strongly implied: use this when you need summary statistics for a numeric column. However, there is no explicit guidance about when to prefer sibling tools such as dataset_search or dataset_top, nor any mention of exclusions or prerequisites.
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 Runsheetly 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?
There are no annotations, so the description carries the full burden. It does not explicitly state that the operation is read-only, how ties are handled, what happens with invalid columns, or any other behavioral details beyond the basic ordering intent.
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 brief, directly to the point, and includes a helpful query-phrase example. No unnecessary words or redundant content.
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 conveys the core purpose and the query pattern, but with no output schema it does not clarify the exact return structure, default limit behavior, or edge cases. It is adequate for a simple tool but leaves some contextual gaps.
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 low at 33%; only ascending has a description. The description adds that the column must be numeric but does not explain limit's default behavior or how it relates to the returned number of rows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The title and description clearly state the operation: ranking rows of a dataset by a numeric column and returning the highest or lowest values. This distinguishes it from sibling tools like dataset_search, dataset_stats, and dataset_row.
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 clear usage context with the 'which is the most/least X' pattern, but it does not explicitly mention when not to use this tool or compare it to alternatives such as dataset_search or dataset_stats.
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!
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 has a clearly distinct purpose: schema, provenance, exact lookup, substring search, multi-value comparison, statistics, and top/bottom ranking. Even the superficially similar dataset_row and dataset_compare are cleanly separated by single-value exact match versus multi-value ordered comparison.
All tools share the consistent dataset_ prefix and follow the same snake_case convention. The names clearly signal their function, and minor verb/noun variation does not create confusion.
Seven tools is well-scoped for a single-dataset querying server. Each tool covers a distinct querying or metadata need without unnecessary redundancy.
The tool surface covers the full lifecycle of exploring and querying the dataset: schema understanding, source attribution, exact lookup, fuzzy search, comparison, numerical statistics, and extreme-value ranking. There are no obvious dead ends for common dataset questions.