Sittingly: 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 Sittingly 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, the description carries the burden of explaining behavior. It discloses what the tool provides (columns, numeric indicators, row count, provenance banner), which suggests a read-only informational operation, but it does not mention side effects, performance, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence that front-loads the output contents and ends with a clear usage directive. Every word earns its place, with no redundant 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 zero-parameter informational tool with no output schema and no annotations, the description adequately specifies what the agent will receive. It could be more explicit about the exact return format, but it is complete enough to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema is empty, so there are no parameter semantics to explain. The description compensates by naming the target dataset and clarifying the tool's role, which is sufficient for a no-argument 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 identifies the tool's purpose: to report the columns, numeric flags, row count, and provenance banner of the Sittingly dataset. It is specific about the resource and output content, though it lacks an explicit verb like 'returns' or 'gets'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The instruction 'Call this first to learn the schema' provides clear guidance on when to use the tool. It implies this tool precedes other dataset operations, but it does not explicitly name alternatives or describe 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 rows of the Sittingly 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?
There are no annotations, so the description carries full burden. It does disclose a genuine behavioral trait — results come back in the order values were given — and the any-of matching semantics. But it does not disclose return format, whether matching is exact or case-sensitive, or how duplicate/absent values are handled.
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 information-dense sentence with no wasted words: it names the resource, parameter roles, ordering behavior, and use case. Everything present earns its place, making it an excellent example of efficient structure.
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 2-parameter tool with no enums or nesting, the essentials for a correct call (parameter roles and ordering) are covered. Yet with no annotations and no output schema, the description should also convey what the result looks like and any matching caveats; those are omitted, leaving moderate 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 description coverage is 0%, so the description must compensate. It does clarify how the two parameters interact: column is the field matched against, values are the list used for any-of matching, in the given order. However, match type (exact vs substring), case sensitivity, and behavior for unmatched values remain unspecified.
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 specifies a concrete behavior: return rows of the Sittingly dataset filtered by matching any given value in a column, preserving the given order. The 'X vs Y questions' framing adds a distinct use case that separates it from siblings like dataset_search or dataset_row, though the verb is implied rather than explicit.
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 'for X vs Y questions' clause signals an intended scenario, which is useful context. However, it never names sibling tools or states when NOT to use them (e.g., when to pick dataset_search or dataset_row instead), leaving routing partly to inference.
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 Sittingly 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 and does well: it states exactly what information is returned (source, date, licence, citation) and the phrase 'Read this' implies a non-mutating retrieval. It could go further by explicitly saying it has no side effects or requires no input, but for this simple metadata tool the behavior is clear.
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 filler. The content list is front-loaded, and the usage directive is appended in a single clear clause. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is complete: it identifies the dataset, the fields available, and the correct use case. An agent has everything needed to decide when to call it and what to expect.
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 input schema has zero properties, so there are no parameter semantics to explain. The description reinforces that the tool is a standalone provenance lookup, which is the appropriate baseline 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 names the exact kind of content the tool provides — source, computed date, licence, and citation for the Sittingly dataset — with an explicit intended action ('attribute a figure correctly'). It clearly distinguishes itself from the sibling tools, which are about columns, search, stats, and row-level data, not provenance.
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?
'Read this to attribute a figure correctly' gives a concrete context for when to call the tool: whenever a figure or result needs citation. It does not explicitly list exclusions or alternatives, but the sibling names make it obvious that this tool is not for data exploration or comparison.
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 Sittingly 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 of behavioral disclosure. It does disclose the case-insensitive matching behavior, which is a useful behavioral trait. However, it does not mention whether the tool returns a single row or multiple rows, what happens if no match is found, or any performance or limit constraints. The ambiguity between 'a row' in the title and 'The rows' in the description is a notable gap.
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 with no filler. It front-loads the core function and the key behavioral detail (case-insensitive). It could be structured more actively, but it 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?
Given no output schema and no annotations, the description does not explain the return format (e.g., whether it returns a list of rows, a count, or a single object). The ambiguity about single vs. multiple rows is unresolved, and error behavior is not mentioned. For a tool with only two parameters, the description is too thin to fully guide an agent on expected results, though it does specify the dataset and matching rule.
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 input schema defines two parameters (column and value) with no descriptions. The description's phrase 'where a column equals a value' adds minimal context, essentially restating the parameter names. It does not clarify what constitutes a valid column (e.g., column name vs index), whether the value must be an exact string, or provide examples. With 0% schema coverage, the description fails to compensate for the lack of parameter 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 clearly states the tool returns rows from the Sittingly dataset where a column matches a value exactly (case-insensitive). The title reinforces this with 'Look a row up by an exact key', and the phrase 'exactly (case-insensitive)' differentiates it from fuzzy search siblings like dataset_search. However, the description is phrased passively ('The rows of...') rather than using an active verb, and it does not explicitly name the sibling it is not.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what the tool does, not when it should be preferred over dataset_search (likely fuzzy matching) or other sibling tools. No exclusions or context are provided, leaving the agent to infer usage from the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Sittingly 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 behavioral disclosure burden. It usefully reveals case-insensitive matching and a hard cap of 50 results, but it does not mention ordering, empty-result behavior, or whether matching applies to all columns. This is 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?
The description is a single efficient sentence with no filler. It front-loads the core behavior, matching rule, and limit in a compact form that is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool, the description covers the essential selection behavior and limit. It lacks explicit return-format details and no-match behavior, but the absence of an output schema makes some ambiguity acceptable for this level of complexity.
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 only 50%, with query documented but limit left to schema type and bounds. The description adds 'up to 50' and 'cells contain the query', which helps, but it does not compensate fully for the undocumented limit semantics or specify format 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 what the tool does: it returns dataset rows whose cells contain the query, with case-insensitive matching and a limit of 50. It is specific about the resource and behavior, though it does not explicitly differentiate itself from siblings like dataset_row or dataset_top.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for finding rows by arbitrary cell content, but it gives no explicit guidance on when to prefer it over alternatives or when not to use it. Sibling tools like dataset_row, dataset_top, and dataset_columns exist, yet no routing information is provided.
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 Sittingly 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 is useful. However, it does not state whether it is read-only, what the output format is, or any error behavior. It gives some behavior 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 sentence that lists the statistics and then adds handling details. It is efficient and front-loaded with the key information, though it is slightly long. 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?
Given the simplicity of the tool (one parameter) and lack of output schema, the description covers the essential functionality. It mentions the dataset and the statistics computed, and the handling of non-numeric rows. However, it does not specify the exact output structure, which might be needed. It is adequate but not exhaustive.
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 specifies the parameter as a string with minLength 1, with zero description coverage. The description adds meaning by indicating the column must be numeric, which is essential. It could be more explicit about the column name format, but it provides necessary 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 states the tool computes summary statistics (count, min, max, mean, median, sum) for a numeric column of the Sittingly dataset. It distinguishes from siblings like dataset_row or dataset_search by its specific purpose, with a specific verb and resource.
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 makes clear what the tool does but does not provide explicit guidance on when to use it versus siblings. There is no mention of alternatives or conditions. An agent might infer to use it when summary statistics are needed, but it lacks explicit routing.
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 Sittingly 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 behavioral disclosure. It mentions 'highest (or lowest)' but does not explain sorting behavior, tie handling, limit semantics, or what happens with non-numeric columns. The description adds minimal value beyond the schema's ascending parameter 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, short sentence with no waste. It front-loads the core purpose. However, it is slightly vague with the quote, but overall it is appropriately concise.
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 ranking tool with no output schema, no annotations, and incomplete parameter documentation, the description is insufficient. It does not clarify limit behavior, ascending default, or output format. The agent would need to guess or rely on the schema, which is also incomplete.
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 only 33% (only 'ascending' has a description). The description helps clarify that 'column' must be numeric, but it does not explain the 'limit' parameter at all. Given low schema coverage, the description should compensate, but it only partially does so for one parameter.
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 purpose: ranking rows by a numeric column to find highest/lowest values. It is specific and distinct from sibling tools like dataset_search or dataset_stats, though it doesn't explicitly name alternatives. The title reinforces this.
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 siblings. It doesn't mention alternative tools or conditions that would make another choice more appropriate. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
dataset_columnsdataset_comparedataset_provenancedataset_rowdataset_searchdataset_statsdataset_topClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes: schema discovery, provenance, exact lookup, substring search, stats, and top/bottom ranking are easy to tell apart. However, dataset_row and dataset_compare overlap in that both do exact column-value matching, with compare merely extending row to multiple values, which could cause some selection uncertainty.
All tools share the clean dataset_ prefix and use lowercase snake_case, making the set feel cohesive. The second part mixes nouns (columns, provenance, row, stats, top) with verbs (compare, search), but the pattern is still predictable and readable.
Seven tools is a well-scoped size for a dataset-querying server. Each tool covers a distinct query need without redundancy or bloat, and the count is comfortably within the ideal range.
The server covers the full read-only lifecycle of working with a dataset: schema discovery, provenance attribution, exact lookup, substring search, comparisons, numeric stats, and top/bottom ranking. There are no obvious dead ends for the stated purpose.