Siftvo: the site's own MCP server — dataset; every answer cites the site.
Scored across 7 tools
Most tools have clearly distinct purposes, but dataset_compare and dataset_row overlap somewhat since both retrieve rows by column value matching. The descriptions help clarify that compare is for ordered multi-value comparisons while row is for single exact matches.
All seven tools follow a consistent dataset_ prefix with a clear noun or verb suffix indicating their function. The naming pattern is uniform and predictable.
Seven tools is a well-scoped set for a read-only dataset exploration server. Each tool covers a distinct mode of querying or describing the Siftvo dataset without unnecessary duplication.
The tool set covers schema inspection, provenance, exact row lookup, substring search, multi-value comparison, numeric statistics, and top/bottom ranking. A minor gap is the lack of a way to retrieve all rows or paginate through the dataset, but for typical dataset Q&A this is sufficient.
The columns, which of them are numeric, the row count and the provenance banner of the Siftvo 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 must carry the behavioral disclosure burden. It discloses what information is returned (columns, numeric indicators, row count, provenance banner) and implies a read-only metadata operation, but it does not explicitly state side effects, permissions, or performance characteristics. The description is adequate but not deeply transparent.
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-loads the key output items, and ends with a clear usage directive. There is no fluff or redundant information, so every sentence 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 simple, parameterless metadata tool with no output schema, the description covers the main return items and gives a clear invocation order. It could be more explicit about the response shape or format, but nothing critical seems missing for an agent to decide to call it.
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 per the calibration baseline this dimension should be scored 4. The description correctly references no inputs and focuses entirely on the output, which is appropriate for a parameterless schema-introspection 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: returning the Siftvo dataset's columns, numeric flags, row count, and provenance banner, plus the directive to call it first to learn the schema. It is specific about the resource and output items, though it does not explicitly differentiate itself from siblings like dataset_stats or dataset_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?
The description gives clear usage context by saying 'Call this first to learn the schema,' which positions it as the initial exploration step. It does not mention alternative tools or when not to use it, but the sequencing guidance is useful and explicit.
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 Siftvo 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?
The description discloses meaningful behavior: rows are returned in the order of the given values, and filtering is by 'any of' those values. However, since no annotations and no output schema exist, the description carries the full burden and does not clarify what the returned comparison actually looks like, whether matches are exact, or how edge cases 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?
The description is a single compact sentence and front-loads the resource and core filtering behavior. The grammar is slightly awkward and the 'X vs Y' purpose is placed at the end, which is acceptable but not ideal.
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 two-parameter read tool, the core selection and ordering semantics are covered, which is enough to make a plausible first call. However, with no annotations and no output schema, the description should also clarify the return representation and handling of absent matches or duplicate values to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the schema's lack of semantic detail. It does clarify that 'column' refers to a dataset column and 'values' are the matching values whose order determines output order. It does not explain value formatting, matching behavior, or maximum constraints beyond what the schema already states.
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 identifies a specific operation: fetching rows of the Siftvo dataset filtered by a column matching any of the given values, in the provided order. It also links the behavior to 'X vs Y' comparison questions, which helps an agent understand its intended role. It does not explicitly contrast this with sibling tools like dataset_row or dataset_search, so it falls short of a 5.
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 an explicit use case for when this tool is appropriate. It implies comparison of specific values rather than general exploration or statistics, but it does not state when not to use it or name alternative sibling tools.
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 Siftvo 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 must carry the burden of behavioral transparency. It states what information is provided, but does not explicitly mention whether the operation is read-only, whether it can fail, or any other side effects. For a simple provenance retrieval, this is acceptable but not fully explicit. There is no contradiction with any annotation because no annotations exist.
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 consists of two concise sentences. The first sentence lists the core content (source, date, licence, citation) and the second provides a practical use case. It is well-structured, with the key information front-loaded, and contains no filler or redundant wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity—no parameters, no output schema—the description is nearly complete. It tells the agent the content and purpose. It does not specify the output format (e.g., a structured object or text), but that is a minor omission for a straightforward provenance getter. Overall, an agent can infer how to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema shows no parameter definitions, meaning 100% coverage. According to the guidelines, when schema coverage is high, a baseline score of 3 is appropriate even if the description adds no extra parameter details. The description does not need to explain parameters because there are none.
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 provides provenance information (source, date, licence, citation) for the Siftvo dataset. Although the verb 'get' or 'return' is implied rather than explicit, the reference to 'read this' makes the purpose understandable. It distinguishes from sibling tools by focusing on provenance rather than data access or comparison.
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 gives concrete guidance: 'Read this to attribute a figure correctly.' This tells the agent when to use the tool (for attribution tasks). It does not explicitly mention alternatives, but the context is clear enough that an agent can infer this tool is for provenance metadata only. The guidance is brief but effective.
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 Siftvo dataset where a column equals a value exactly (case-insensitive).
| Name | Required | Description | Default |
|---|---|---|---|
| value | Yes | ||
| column | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It contributes the important traits that matching is exact and case-insensitive, and it implies a read-only lookup. However, it does not disclose return shape, whether one or all matching rows are returned, or error/limit 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 a single sentence with no filler and puts the core exact-match behavior up front. Slight grammatical awkwardness ('The rows ... where') and ambiguity between singular title and plural description prevent a top score.
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 lookup with no output schema and no annotations, the description covers the core matching behavior but leaves important gaps: it does not clarify whether all matching rows or a single row are returned, does not state column-existence requirements, and provides no usage guidance or output expectations.
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 add parameter meaning. It does connect 'column' and 'value' to the equality filter and adds case-insensitive semantics. But it does not explicitly say column is a column name, whether column names are case-sensitive, or provide any examples or format details.
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 states a clear verb+resource ('Look a row up by an exact key'), and the description adds the key semantic: rows where a column exactly matches a value, case-insensitively. This distinguishes it from a fuzzy search, though it never explicitly names dataset_search as the sibling to compare against.
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 exact-match usage but provides no explicit guidance about when to choose this tool over sibling tools like dataset_search. There is no mention of alternatives, exclusions, or conditions that would make another tool more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Siftvo 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 burden of behavioral disclosure. It does disclose case-insensitive substring matching and a 50-row cap, but it does not mention ordering, empty results, authentication, rate limits, or the structure of returned rows.
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, information-dense sentence with no filler. It front-loads the result type and includes the case-insensitivity and limit behavior efficiently.
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 covers the core operation and the row cap. However, with no output schema and no annotations, it omits return format, ordering, empty-result behavior, and any guidance relative to sibling tools, 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 coverage is only 50%, so the description must compensate for the undocumented limit parameter. The phrase 'up to 50' clarifies the limit parameter's maximum, adding value beyond the schema. Query semantics are already described in the schema, so the description adds little there.
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 tool name and title clearly indicate a search operation. The description states what it returns—rows whose cells contain the query, case-insensitive, up to 50—making it distinct from siblings like dataset_row or dataset_stats, though no explicit contrast is made.
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 statement of when to use this tool versus alternatives such as dataset_row or dataset_top. The intended use is implied by the name and title, but no conditions, exclusions, or routing guidance are 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 Siftvo 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 must carry behavioral disclosure. It usefully reveals that grouping commas and currency are handled and that non-numeric rows are excluded, but it leaves ambiguity about whether 'counted' means a separate count is returned, and it does not address missing-column or all-non-numeric edge cases.
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 that front-loads the computed statistics and then adds only meaningful caveats about parsing and non-numeric handling. No filler or repetition exists.
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 one-parameter tool, it covers the core operation and important data-cleaning behavior. However, because there is no output schema, the description would benefit from stating the return structure and behavior when no numeric rows exist or when the column 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 schema has one undocumented 'column' parameter, and the description clarifies that it refers to a numeric column. It does not explicitly explain the expected column name format or how to discover valid column values, though the single self-named parameter is fairly self-evident.
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 count, min, max, mean, median, and sum for a numeric column of the Siftvo dataset. This makes its purpose distinct from sibling tools like dataset_row, dataset_top, or dataset_search.
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 context is clear: use this when summary statistics for a numeric column are needed. However, it does not explicitly mention alternatives or when not to use it, so the agent must infer the appropriate selection from the operation list.
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 Siftvo 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?
No annotations are provided, so the description carries the full burden of disclosing behavior. It explains the high/low ranking concept but does not disclose default sorting behavior, limit handling, tie-breaking, or what the returned rows look like. The schema covers ascending/limit, but the description adds little behavioral context beyond the one-line purpose.
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 immediately conveys the tool's purpose and unique value. It is front-loaded and contains no filler, though the quoted phrase is slightly informal.
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 and no annotations, the description should provide enough context for invocation and result interpretation. It does not mention return format, pagination, default limit, or error conditions for non-numeric columns. The simple concept is captured, but several practical details an agent would need are absent.
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%, so the description must compensate. It does add meaning by stating the column must be numeric and that the tool can return highest or lowest, which maps to ascending. However, it says nothing about the `limit` parameter or its semantics, and only indirectly references `ascending`. For a three-parameter tool, this is insufficient compensation.
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 it ranks rows by a numeric column and supports both highest and lowest values. The phrase 'which is the most/least X' gives an intuitive sense of the tool's purpose, and it is distinct enough from siblings like dataset_search or dataset_stats. It does not explicitly name a sibling, but the core action and resource are clear.
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 through the 'most/least X' framing, which tells the agent this is for identifying extreme rows rather than searching or summarizing. However, it gives no explicit guidance on when to prefer this over alternatives, nor any exclusions or prerequisites such as requiring a numeric column to exist.
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.
dataset_columnsdataset_comparedataset_provenancedataset_rowdataset_searchdataset_statsdataset_topSopvo: the site's own MCP server — dataset; every answer cites the site.
Sbarvo: the site's own MCP server — dataset; every answer cites the site.
Funnelvo: the site's own MCP server — dataset; every answer cites the site.
Nofovo: the site's own MCP server — dataset; every answer cites the site.
Add one secure layer between your agents and this server.
