Opexvo: 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 Opexvo 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 burden of explaining behavior. It discloses what the tool returns, and "Call this first" implies a safe read-only operation, but it does not explicitly state side-effect-freeness, access requirements, or any limits.
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, front-loading the output contents and then the key usage instruction. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description enumerates the main return elements (columns, numeric flags, row count, provenance banner), which is enough for an initial schema-discovery call. It does not describe the exact structure of those elements, but the context is simple enough that this is a minor gap.
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 zero parameters, so the input schema cannot create ambiguity and the baseline is 4. The description does not need to document parameter semantics 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 names the concrete outputs — columns, numeric flags, row count, and provenance banner — for the Opexvo dataset, and adds the directive to call it first. It does not use an explicit verb or directly contrast with siblings like dataset_provenance or dataset_stats, so it stops 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?
"Call this first to learn the schema" gives explicit placement in an agent's workflow. It does not name alternatives or specify when not to use it, but for a zero-parameter exploratory tool the guidance is 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 Opexvo dataset whose column is any of the given values, in the order given — for "X vs Y" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| column | Yes | ||
| values | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It usefully reveals that rows are selected by membership in the given values and returned in the given order, but it does not disclose exact-match semantics, handling of missing values, output format, 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?
A single, tightly written sentence that front-loads the core behavior and closes with the intended use case. There is no filler, and every clause contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the description covers the essential selection and ordering behavior, but with no output schema and no annotations, the lack of detail about the returned structure and edge cases leaves some ambiguity. It is adequate but not comprehensive.
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 bare parameter definitions. It names both parameters and adds meaningful semantics: the column is the filtering field, and the values determine both inclusion and output ordering. Still, it could clarify that 'column' is an existing column name and what value formats are expected.
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 operation: returning rows from the Opexvo dataset filtered by values in a given column, preserving the provided order. It also signals its distinctive niche ('X vs Y' questions), which partially distinguishes it from siblings like dataset_row or dataset_search, though it does not explicitly name them.
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 situational context for when this tool is appropriate. However, it does not explicitly state when not to use it or point to alternatives among the sibling tools, so it stops short of full routing guidance.
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 Opexvo 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 provided, the description itself signals a read-only operation ('Read this') and enumerates exactly what will be returned: source, computed date, license, and citation. It could be more explicit about having no side effects, but the described behavior is adequately transparent for a zero-parameter metadata 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 filler. It front-loads the concrete content items and ends with a clear instruction on when to use it.
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, no-output-schema provenance lookup, the description is complete: it states what data is returned, the dataset it applies to, and the intended use. No additional context is necessary for correct invocation.
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 there is no schema information to supplement. The description's enumeration of the returned provenance fields provides all the semantic context an agent needs.
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 role: it exposes provenance metadata—source, computed date, license, and citation—for the Opexvo dataset. This is distinctive from the sibling tools, which handle columns, search, stats, and rows rather than provenance or attribution.
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 'Read this to attribute a figure correctly' gives a clear, concrete use case: citation and attribution. It does not explicitly list alternatives or exclusion conditions, but for a simple metadata retrieval tool this context is 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 Opexvo 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?
The description does disclose exact equality and case-insensitivity, which are useful matching semantics. However, with no annotations, it leaves unclear whether one row or all matching rows are returned, what happens on no match, and what the response shape is; the title's 'a row' and description's 'rows' even conflict.
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?
One compact sentence that front-loads the core lookup condition. It contains no filler or repetition and is 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?
For a simple lookup the core condition is stated, but with no output schema and no annotations the description omits return cardinality, no-match behavior, and any interaction with sibling search tools. These gaps leave an agent uncertain on important call details.
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 minLength for both parameters and no descriptions, so coverage is 0%. The description adds the core semantic that 'column' is the field and 'value' is the equality target with exact case-insensitive comparison, but it gives no guidance on valid column names, value formats, or special cases.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns rows from the Opexvo dataset where a column equals a value, and the title adds the 'exact key' lookup intent. It is specific about verb and resource, though it does not explicitly distinguish itself from 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?
No sentence explains when to use this tool instead of dataset_search, dataset_top, or other siblings. There are no exclusions or prerequisites, so an agent must infer applicability from the name and title alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rows of the Opexvo 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 disclosure burden. It reveals important behavior: case-insensitive matching, substring-like cell containment, and a 50-row cap. It does not describe return structure, ordering, or default limit behavior, but the core search behavior is transparent enough for a 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?
A single, front-loaded sentence packs the essential behavior, matching criterion, case sensitivity, and row cap without extraneous words. Every element 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 two-parameter search tool with no output schema, the description covers the critical behavior: what is searched (cells), how (case-insensitive containment), and the upper bound (50). Minor gaps like default limit and return column set do not seriously impede correct invocation.
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 already described as 'text to look for in any cell', and limit has min/max constraints. The description adds the case-insensitive detail and reinforces the 50-row cap, but it does not clarify the default limit or output shape.
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 is specific and action-oriented: it returns rows of the Opexvo dataset whose cells contain the query, case-insensitively, up to 50. This clearly distinguishes it from sibling tools like dataset_columns, dataset_row, or dataset_stats, which have 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?
The behavior implies when to use it: when you need to find dataset rows by searching cell text rather than by known row identity or column analysis. However, it does not explicitly state when not to use it or mention any sibling alternatives, leaving usage guidance implicit.
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 Opexvo 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 and does disclose non-obvious parsing behavior: grouping commas and currency are handled, and non-numeric rows are excluded and counted. However, it does not clarify the return format, and the phrase 'excluded and counted' is ambiguous as to whether the reported count represents numeric rows or excluded 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 single sentence front-loads the result list, scopes the resource, and appends parsing details in a parenthetical. Every clause carries distinct information with no redundancy or 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?
For a one-parameter tool with no output schema, the description covers purpose, parameter semantics, and key behavioral quirks. It stops short of specifying the exact return shape or edge-case behavior, but this is a minor gap given the tool's low 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?
The schema only defines 'column' as a string with no description. The tool description adds meaning by specifying that the column must be numeric and by describing how values are processed (commas/currency handled, non-numeric excluded), which helps an agent select appropriate input.
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 statistics produced (count, min, max, mean, median, sum) and the target resource (a numeric column of the Opexvo dataset), which clearly distinguishes it from siblings like dataset_row or dataset_search. The title reinforces this purpose.
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 use when summary statistics of a numeric column are needed, but it does not explicitly state when to prefer this tool over siblings such as dataset_top or dataset_search, nor any exclusions. Usage guidance is only implicit.
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 Opexvo 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 only restates the ranking concept ('highest or lowest') which is already covered by the 'ascending' parameter in the schema. It does not disclose default limit behavior, handling of non-numeric columns, return format, or potential side effects. The description adds minimal new behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose and includes a clarifying example. There is no fluff or redundant phrasing, and it is appropriately sized for a simple 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?
Given the tool has 3 parameters, no output schema, and no annotations, the description is insufficient. It does not specify default values for 'limit' (e.g., whether a limit is mandatory or defaults to a certain number), nor does it explain the return format (e.g., array of rows, columns included). An agent cannot confidently call this tool without additional assumptions.
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% (only 'ascending' has a description). The description mentions 'numeric column' but does not explain the 'column' parameter's format or constraints, nor does it clarify the 'limit' parameter's default or behavior. It fails to compensate for the low schema coverage, leaving the agent with ambiguity about required and optional parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool ranks rows of the dataset by a numeric column, with an explicit 'highest or lowest' clarification and a colloquial example ('which is the most/least X'). It is specific about the resource (Opexvo dataset) and distinguishes itself from sibling tools like dataset_search or dataset_stats by focusing on ranking/top-N.
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 'which is the most/least X' but provides no explicit guidance on when to prefer this tool over siblings (e.g., when you need aggregated statistics vs. top rows). There is no mention of alternatives or exclusion criteria, so usage is only implied, not clearly delineated.
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.
Each tool has a distinct primary purpose: schema, provenance, exact row lookup, substring search, multi-value comparison, summary stats, and top/bottom rankings. The main ambiguity is between dataset_row and dataset_compare, since both do exact value filtering, though one is single-value and the other is multi-value/ordered.
All tools share a clean dataset_ prefix and use snake_case, making the family immediately recognizable. The second part mixes noun forms (columns, provenance, row, stats) with verb-like forms (compare, search, top), so the pattern is not perfectly uniform but remains readable and predictable.
Seven tools is a well-scoped size for a read-only dataset exploration server. Each tool covers a distinct need without redundancy or unnecessary bloat.
The tool surface covers the full read-only dataset workflow: schema discovery, row retrieval by exact match, substring search, multi-value comparison, numeric summaries, ranking, and provenance/attribution. There are no obvious missing operations for the stated purpose.