VeriTR

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.1
Disambiguation5/5
Each tool targets a distinct operation: searching indicators vs raw datasets, fetching series vs snapshots, comparing regions vs comparing series, plus metadata, sources, and analysis. Descriptions explicitly clarify edge cases (e.g., get_series vs get_snapshot), so there is no ambiguity.
Naming Consistency5/5
All tool names follow a consistent verb_noun snake_case pattern (search_*, get_*, compare_*, analyze_*). The verbs and nouns clearly match the tool's function, and there are no mixed conventions or vague names.
Tool Count5/5
Nine tools is well-scoped for a statistical data access server. Each tool covers a distinct need (discovery, retrieval, comparison, metadata, sources, analysis) without redundancy or bloat.
Completeness5/5
The tool set covers the full workflow: discover indicators (search_indicators), fall back to raw catalogs (search_datasets), fetch series (get_series), get cross-sectional snapshots (get_snapshot), compare across regions or indicators (compare_regions/compare_series), understand definitions (get_metadata), diagnose availability (get_sources), and perform analysis (analyze_series). No obvious gaps for the stated purpose.
Average 4.3/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 19 commits in the last 12 weeks
- Last stable release on August 18, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey safety. It describes the operation as deterministic statistics but does not explicitly state that it is read-only or lacks side effects, leaving some ambiguity. It doesn't mention error behavior or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, and no filler. The context about avoiding transcription errors is useful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the main purpose and use case, and the output schema handles return-value documentation. It omits guidance on parameter interplay (e.g., window size vs. date range) but is reasonably complete for a computation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33%, and the description only alludes to operations (growth rates, moving average, etc.) without explaining window, date boundaries, or geography. It adds value for operations but leaves other parameters underdocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool computes deterministic statistics (growth rates, moving average, rebasing, min/max/mean) on a single series, distinguishing it from siblings like get_series and compare_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly advises using this over manual arithmetic when the series has many observations, providing a clear use case. It does not, however, specify when not to use it relative to comparative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses an important behavior: 'Frequency mismatches are reported explicitly and never silently resampled.' But it does not mention whether the operation is read-only, error behavior, or other side effects. The description adds some behavioral 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four concise sentences cover purpose, use case, a critical behavioral guarantee, and a parameter tip. The most important information is front-loaded, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 6 parameters and an output schema, the description covers the key decision points: cross-source comparison, frequency mismatch handling, and normalization. It doesn't explain the correlate parameter, but the schema does, and the output schema covers return values. It's complete enough for an agent to select and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 67%, so the description should compensate for gaps. It adds meaningful guidance for 'normalize' ('when units differ') and clarifies that indicators can be from different institutions, but does not explain start_date/end_date or geography beyond the schema. This adds some value but doesn't fully flesh out all parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Compare SEVERAL indicators — possibly from different institutions — side by side,' a specific verb+resource+scope. This clearly distinguishes it from sibling tools like get_series (single series) and compare_regions (regional comparison).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States a clear use case ('This is what makes cross-source questions answerable') with a concrete example, and gives conditional guidance ('Set normalize=true when units differ'). However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses return format ('compact [period, value] pairs plus the source institution and dataset id') and a key behavioral trait ('Omitting geography returns every region'). It could add more about pagination or error behavior, but the essentials for a safe read operation are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each earning its place: what it does, what it returns, and how to vary its scope. It is front-loaded with the action and resource, and the alternative tool reference is tucked naturally into the final sentence. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there are 7 parameters and no annotations, the description covers the most important context: its role as primary data tool, return structure, and the behavior of omitting geography. Because an output schema exists, deep return documentation is unnecessary. It does not mention date handling or dimensions, but the schema already documents those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description need not restate parameter meanings. It does add a usage hint for combining limit and geography for national comparisons, but this is more a suggestion than semantic enrichment beyond the schema's already clear descriptions. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb and resource: 'Fetch a time series for one indicator.' It also labels itself as 'the primary data tool,' which immediately distinguishes it from sibling tools like get_snapshot or compare_series. The explicit contrast with get_snapshot ('for a single-year ranking') further reinforces its unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the primary data tool,' signaling when it should be preferred. It also provides a concrete alternative: 'use get_snapshot for a single-year ranking.' It gives usage context for geography and limit ('combine with limit for national comparisons'), though it doesn't explicitly exclude other comparative tools like compare_series.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the transparency burden. It adds valuable behavioral traits: 'Search works in Turkish and English and is accent-insensitive,' and clarifies the return type ('VeriTR indicator ids'). It also implies a read-only operation via 'search.' This goes beyond the schema and helps the agent understand behavior, though it could note more about response structure or limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: a clear main sentence, followed by a high-visibility usage note, then a brief return and language note. Each sentence earns its place, and the use of 'USE THIS FIRST' is an effective attention hook. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, 1 required), an output schema exists, and schema coverage is high. The description covers the essential workflow (use before get_series), return format, and language behavior. It does not list all filter options, but the schema handles those. It is adequately complete for a search tool, though it could explicitly confirm read-only operation if annotations were absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 83%, above the 80% threshold, so baseline is 3. The description does not add parameter-specific semantics beyond what the schema already provides (e.g., the query parameter's language support is mentioned but the schema examples already capture this). The tool name and description together imply the query is a search term, but the schema handles the details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Search VeriTR's normalized indicator catalog.' It uses a specific verb ('search') and resource ('normalized indicator catalog'), and immediately distinguishes itself from sibling tools by instructing to use this before get_series. This is a clear, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'USE THIS FIRST, before get_series, whenever the exact indicator id is unknown.' This is a clear use case and references a sibling tool. However, it does not explicitly mention when NOT to use it or discuss other alternatives like search_datasets, so it stops short of full alternative coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
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 describes what the tool returns (unit, frequency, geography, overrideable dimensions, source dataset, official URL), which lets the agent anticipate the output. It does not explicitly state side effects or auth requirements, but for a metadata getter, the disclosure is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, with a clear subject-action object in the first sentence and a focused usage trigger in the second. Every phrase adds value, and it adheres to front-loading. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, an output schema, and a clear purpose, the description is complete for an agent to decide when to use it. It explains what to retrieve and when to invoke it. The output schema covers return structure details, so the description need not explain those.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the parameter has a description: 'VeriTR indicator id.'). The description adds no parameter syntax or format details beyond the schema, so the baseline 3 applies. The mention of 'override dimensions in get_series' provides context but does not enhance understanding of the 'indicator' parameter itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Get the full definition of an indicator') and lists key return elements (unit, frequency, geography coverage, overrideable dimensions, source dataset, URL). It clearly distinguishes from sibling tools like get_series by mentioning which dimensions may be overridden there.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance: 'Call this when get_series arguments are unclear.' This signals the tool's role as a prerequisite/disambiguation tool, though it does not enumerate exclusions for other siblings. The context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It usefully discloses that each region gets its own series plus a summary (first/last value, total change), which is meaningful 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences: opening purpose statement, output behavior detail, and alternative tool pointer. No filler, front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output summary behavior, and alternative usage. With an output schema present, return values need no explanation, so this is nearly complete for a tool of this complexity, though date handling defaults are left implicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%, and the description adds conceptual meaning for indicator and regions (one vs. several) but provides no added semantics for start_date or end_date. The date parameters are implied by 'over time' but not explicitly explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool compares ONE indicator across SEVERAL regions over time, using a specific verb and resource. It explicitly differentiates from compare_series by contrasting one-indicator-multiple-regions vs. multiple-indicators.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use this tool (comparing one indicator across multiple regions) and names the alternative (compare_series) for comparing multiple indicators. This is clear usage guidance with an explicit exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It states that it searches raw catalogs and implies a read-only operation, and it notes that it returns metadata (not rows) by suggesting a follow-up with get_dataset. While it doesn't exhaustively describe all behavioral aspects, it provides sufficient context for this 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, well-structured, and free of fluff. It conveys the purpose, usage context, and additional notes in a compact paragraph, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
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 provides sufficient context: it clarifies the scope (raw catalogs), differentiates from search_indicators, and gives language indexing tips. Since an output schema exists (though not shown), the return type is likely specified elsewhere, so the description doesn't need to explain it. The only minor gap is not detailing the exact output format, but this is acceptable given the output schema's presence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers most parameters: 'query' and 'provider' have descriptions, but 'limit' only has constraints. The description adds little beyond the schema, though it does clarify that TÜİK index is in English and İBB in Turkish, which indirectly informs the 'provider' parameter. Overall, schema coverage is high, so the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: searching raw dataset catalogs from source institutions. It distinguishes itself from the sibling tool 'search_indicators' by explicitly noting when to use it, providing a clear 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.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Use this when search_indicators returns nothing useful, and always for city-level questions about İstanbul.' It also recommends a follow-up action (get_dataset), making the when-to-use context very clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses pagination behavior (page with offset, response says how many rows were withheld), and what it returns (field list, page of rows, total count, licence). It does not mention auth or side effects, but for a read tool this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact (5 sentences), front-loaded with purpose, and every sentence adds value—distinguishing tool, explaining scope, and outlining return/pagination. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, the description need not detail return structure; it still summarizes key outputs. It covers usage guidance, pagination, scope, and how it differs from related tools. The description fully addresses what an agent needs to know, given the moderate parameter complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 50% (limit and offset lack descriptions). The description explains the offset-based pagination and that the response reports withheld rows, giving some meaning to limit/offset. It does not explicitly describe each parameter, and the provider semantics are already in the schema. The description partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Read the columns and rows') on a specific resource ('raw dataset'), and explicitly contrasts with get_series ('use get_series for national indicators and this for city datasets'), distinguishing it from siblings. This is a clear, actionable purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit when-to-use guidance: 'use get_series for national indicators and this for city datasets' and mentions the prerequisite 'found via search_datasets'. This clearly directs the agent to the correct tool among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses key behavioral traits: 'ranked', 'single point in time', and 'ALL regions'. It does not discuss tie handling, data gaps, or default ordering, but the output schema likely covers return structure, and the description clearly indicates the core behavior. A slight gap remains in not mentioning what happens with missing data or exact ranking semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core definition and immediately followed by usage guidance. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, a clear purpose, explicit usage context, and a complete output schema, the description is sufficient. It tells the agent what the tool does, when to use it, and how it differs from alternatives, leaving no critical gaps for selection or invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all four parameters fully described in the schema. The description only adds that 'one indicator' refers to the indicator parameter, which doesn't meaningfully extend beyond the schema. According to guidelines, baseline 3 is appropriate when schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one indicator's value across all regions at a single point in time, ranked. It explicitly distinguishes itself from get_series by noting it should be used for 'which provinces have the highest/lowest X' questions, which differentiates it from the sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence gives explicit usage guidance: 'Use this for "which provinces have the highest/lowest X" questions instead of calling get_series once per province.' This clearly states when to use the tool and explicitly names an alternative, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the tool's behavioral role: it provides live availability status and supports diagnosing missing API keys, provider outages, or unsupported topics. This adds meaningful context beyond the schema, though it doesn't cover all potential behaviors (e.g., pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences; the first front-loads the core action, the second provides a clear use case. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description sufficiently covers purpose and usage context. It explains the diagnostic use case and the nature of the output (institutions + availability), making it complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline for parameter semantics is 4. The description doesn't need to explain parameters, and it doesn't.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the verb 'List' with a specific resource ('every institution VeriTR can reach') and adds 'with live availability status,' clearly distinguishing it from sibling tools like search_indicators or compare_series.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The second sentence explicitly states when to use: 'when a query fails,' and explains the diagnostic purpose, but it does not specify when not to use it or mention alternatives, so not a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![VeriTR-MCP MCP server](https://glama.ai/mcp/servers/ulascan54/VeriTR-MCP/badges/card.svg)](https://glama.ai/mcp/servers/ulascan54/VeriTR-MCP)

Score Badge

Copy to your README.md:

[![VeriTR-MCP MCP server](https://glama.ai/mcp/servers/ulascan54/VeriTR-MCP/badges/score.svg)](https://glama.ai/mcp/servers/ulascan54/VeriTR-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/ulascan54/VeriTR-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server