dataset_provenanceThe source, the date it was computed, the licence and the citation for the HomeCover HQ dataset. Read this to attribute a figure correctly.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of explaining behavior. It discloses exactly what information the tool provides (source, date, licence, citation) and implies a read-only operation via 'Read this'. It does not describe output format, but the content is simple enough that this is not a significant 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?
Two concise sentences with no filler. The first sentence enumerates the actual contents, and the second gives the practical purpose. Everything present 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, no-side-effect metadata retrieval tool, the description is complete: it states what data is returned and why an agent would call it. There is no output schema, but the enumerated fields (source, date, licence, citation) effectively describe the expected return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema already fully covers the input contract. Per the baseline for zero-parameter tools, the description does not need to add parameter-level detail, and its content correctly focuses on what the tool returns.
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 (HomeCover HQ dataset) and the exact content returned: source, computed date, licence, and citation. It is clearly distinguishable from sibling tools like dataset_row, dataset_stats, and dataset_columns, which concern data content rather than 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 phrase 'Read this to attribute a figure correctly' gives a clear use case: citation and attribution. It does not explicitly name alternatives or exclusion cases, but no sibling tool serves this provenance purpose, so 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.
Add one secure layer between your agents and this server.
Most tools have clearly distinct purposes: schema, provenance, exact row lookup, substring search, comparison, stats, top values, and enquiry steps are all separate. The only mild ambiguity is between dataset_row, dataset_search, and dataset_compare, but their descriptions clarify exact matching, substring matching, and ordered value comparison respectively.
The dataset_* prefix and enquiry_* prefix create a clear grouping. Within each group the pattern is mostly consistent, though some names are noun-based (dataset_columns, dataset_provenance) while others are verb-based (dataset_search, dataset_compare), and submit_enquiry reverses the prefix order.
Ten tools is a well-scoped set for this domain: seven query tools cover the dataset surface and three cover the enquiry flow. Each tool has a distinct job and none feel redundant.
The dataset side covers schema discovery, provenance, exact lookup, search, comparison, statistics, and ranking, which covers the full range of likely questions. The enquiry side handles explaining the process, listing fields, and submitting with a two-step confirmation, leaving no obvious dead ends.