Search 30,000+ decided U.S. DOHA security-clearance decisions, cited to the public record.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4/5 across 7 of 7 tools scored.
Each tool targets a distinct aspect of the DOHA case record: searching, fetching full case, finding similar cases, and four different statistical analyses (candor, conduct recency, timelines, overall statistics). There is no ambiguity between tool purposes.
Most tools use a 'get_' prefix, but 'search_cases' uses 'search_' and 'similar_cases' uses an adjective instead of a verb. This mix of conventions, while readable, lacks a consistent pattern.
Seven tools is well-scoped for the domain of exploring DOHA security clearance decisions. It covers both data retrieval (search, case fetch, similarity) and various descriptive statistics without being overwhelming.
The tool surface covers core operations: search, case detail, similarity, and key statistics. Minor gaps exist, such as no tool for listing all guidelines or judges, but these are not essential for the primary analysis purpose.
get_candor_outcomesAHow cases with a candor allegation (falsification, omission, or lack of candor) were resolved in the decided record: the favorable rate with vs without such an allegation, when the judge found a deliberate falsification vs when the applicant rebutted it, and when the applicant corrected the record before being confronted. Counts and denominators throughout. Descriptive, never a prediction.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds valuable behavioral details: it is descriptive (not predictive), provides counts and denominators, and explains the scope (allegations of falsification, omission, lack of candor). No contradictions with annotations.
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 paragraph that front-loads the main purpose but includes some redundancy (e.g., 'Counts and denominators throughout' reemphasizes prior information). It could be slightly more concise by omitting repetitive phrases.
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 parameters and no output schema, the description fully explains what the tool returns. It covers the key analytical breakdowns and sets expectations (descriptive, not predictive). Minor lack of explicit usage guidelines prevents a 5.
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 no parameters, so schema coverage is trivially 100%. The description compensates by explaining the nature of the output (favorable rates, counts, denominators), adding meaning beyond the empty input schema.
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 provides outcome breakdowns for candor allegation cases, including specific sub-analyses (favorable rates, deliberate falsification, rebuttals, corrections). It distinguishes itself from siblings like get_case and get_statistics by focusing on a specific aggregated analysis.
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 for descriptive analysis of candor outcomes, noting 'Descriptive, never a prediction.' However, it does not explicitly state when to use this tool versus siblings like get_statistics or search_cases, leaving usage context partially implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_caseAFetch one decided DOHA case in full: what was alleged, the judge's findings per allegation, per-guideline formal findings, outcome, judge, representation, and appeal history. Use case_id from search_cases.
| Name | Required | Description | Default |
|---|---|---|---|
| case_id | Yes | The numeric case id from search_cases |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already confirm readOnlyHint=true and destructiveHint=false. The description adds behavioral context by detailing the output contents (allegations, findings, outcome, etc.), which goes beyond the structured fields. No contradictions or missing traits like rate 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 concise sentences, front-loaded with the core purpose. Every word adds value; no fluff or repetition.
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 tool with one parameter and no output schema, the description compensates by listing all key output components (allegations, findings, outcome, etc.), making it complete enough 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?
Schema coverage is 100% and the schema already describes case_id as 'The numeric case id from search_cases'. The description repeats this guidance but adds no new semantic value beyond what the schema provides, meeting the baseline.
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 verb 'Fetch' and the resource 'one decided DOHA case in full'. It enumerates specific content (allegations, findings, outcome, etc.), distinguishing it from sibling tools like search_cases (searching) and get_candor_outcomes (specific aspect).
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 explicitly says 'Use case_id from search_cases', guiding the agent to call search_cases first. It implies context but does not explicitly state when not to use this tool or provide alternatives beyond the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_conduct_recencyAHow much time had passed between the most recent conduct and the decision, measured from dates stated in the decisions, for the incident-type concerns (drugs, alcohol, criminal conduct, sexual behavior, protected information, IT misuse). Reports median years before favorable vs unfavorable decisions, with counts. Descriptive association, never a prediction.
| Name | Required | Description | Default |
|---|---|---|---|
| guideline | No | Optional single concern letter to scope to: H drugs, G alcohol, J criminal, D sexual behavior, K protected information, M IT misuse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and non-destructive behavior. The description adds valuable context: it is descriptive (not predictive), reports median years and counts, and covers specific concern types. This goes beyond annotations and clarifies behavioral traits.
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, both informative and necessary. It front-loads the main action and adds key constraints (descriptive, not predictive) without redundancy. 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?
Given the single optional parameter and annotations, the description covers the tool's purpose, inputs, and output structure (median years, counts). It clarifies the descriptive nature. Minor details like handling of missing data are absent, but overall it is fairly complete for the tool's 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 input schema already fully describes the single optional parameter 'guideline' with its values and mapping. The description reiterates the concern types but does not add substantial meaning beyond the schema. With 100% schema coverage, baseline is 3, and the description's contribution is marginal.
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 measures the time between the most recent conduct and the decision, and reports median years for favorable vs unfavorable decisions. It lists the specific incident-type concerns covered, making the purpose specific. However, it does not explicitly distinguish from sibling tools like 'get_statistics' or 'similar_cases', so clarity is high but not maximal.
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 when recency of conduct is relevant and explicitly states it is descriptive, not predictive. However, it does not provide explicit when-to-use or when-not-to-use guidelines or mention alternatives among sibling tools, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_statisticsAGrant/denial statistics over decided hearing-level DOHA cases, grouped by year or by guideline, always with sample sizes. Same population rules as the site's Insights page.
| Name | Required | Description | Default |
|---|---|---|---|
| by | No | Grouping (default year) | |
| year_to | No | ||
| guideline | No | Optional single guideline letter A-M to scope to | |
| year_from | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and destructiveHint=false, so the description adds value by stating 'always with sample sizes' and specifying grouping options. This provides behavioral context beyond the annotations without contradiction.
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 sentences with no fluff. The main action and key details (grouping, sample sizes, population rules) are front-loaded, earning their 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 tool with 4 parameters and no output schema, the description could be more complete. It lacks details on the output structure (beyond sample sizes) and does not explain the 'same population rules' reference. With good annotations, the bar is lower, but the description still feels somewhat incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%, with 'by' and 'guideline' documented. The description mentions grouping by year or guideline, partially covering the parameters. However, year_from and year_to lack schema descriptions and the description does not explain their format or range, leaving a gap for undocumented 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 retrieves grant/denial statistics over decided hearing-level DOHA cases, with grouping by year or guideline. The verb 'get' and resource 'statistics' are specific. It distinguishes from sibling tools like get_case or search_cases by focusing on aggregate data.
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 mentions 'Same population rules as the site's Insights page,' which provides some context about the data source, but it does not explicitly state when to use this tool vs alternatives or provide guidance on prerequisites or filtering.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_timelinesAMeasured DOHA timelines: median days from Statement of Reasons to hearing and to decision, from dates stated in the decisions themselves. Optionally scoped to one decision year.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | Optional decision year to scope to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful context: the metrics are median days, and the data source is dates stated in decisions themselves. This explains core behavior beyond annotations.
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 sentences with no wasted words. The first sentence states what the tool does and how, the second specifies the optional parameter. Perfectly concise and front-loaded.
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 read-only tool with one optional parameter and no output schema, the description adequately explains the output (median days for two durations) and scoping. It is complete for the tool's complexity, though return format could be slightly more explicit.
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 100% with the parameter 'year' having a description. The tool description adds 'Optionally scoped to one decision year,' but this is redundant with the schema description. Baseline 3 as description does not significantly enhance schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns measured DOHA timelines: median days from Statement of Reasons to hearing and to decision. It identifies the specific resource (DOHA timelines) and the action (retrieve). It implicitly distinguishes from siblings like get_statistics by being more specific, though no explicit differentiation is provided.
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 mentions optional scoping by decision year, which gives guidance on using the parameter. However, it does not explicitly state when to use this tool versus alternatives like get_statistics or search_cases, nor does it provide when-not-to-use or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_casesASearch 30,000+ decided public DOHA security-clearance decisions (1996 to present). Full-text query plus filters. Returns matching cases with outcome, date, guidelines, and a citable URL each.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Decision level | |
| limit | No | Max results, 1-25 (default 10) | |
| query | No | Full-text search, e.g. "gambling debts sports betting" | |
| outcome | No | Final outcome filter | |
| year_to | No | Latest decision year | |
| guideline | No | Single guideline letter A-M (e.g. F = financial, B = foreign influence) | |
| year_from | No | Earliest decision year, e.g. 2020 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false, so the description does not need to restate that. The description adds value by specifying return fields (outcome, date, guidelines, URL) and the date range, but could mention pagination or default sorting 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?
Two sentences: first sets scope and nature, second describes results. No fluff, front-loaded with key information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially details return fields (outcome, date, guidelines, URL). It covers the tool's main purpose and important constraints (date range). It omits explicit mention of default limit, pagination, or error handling, but these are implied by the schema and common sense.
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 100% (all parameters described). The description adds example values (e.g., 'gambling debts sports betting' for query, 'F = financial' for guideline) and contextualizes year_from/year_to with the overall date range, providing extra meaning beyond the schema.
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 verb 'Search', the resource 'public DOHA security-clearance decisions', the scope (30,000+ decisions, 1996–present), and the return fields (outcome, date, guidelines, URL). This distinguishes it from sibling tools like get_case and similar_cases.
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 for broad search over security-clearance decisions using full-text query and filters. Sibling tool names allow inference of when to use alternatives (e.g., get_case for a single case, get_statistics for aggregates), but no explicit when-not-to-use or alternative mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
similar_casesAThe most similar decided cases to a given case, ranked by how alike the ALLEGATIONS read (never by outcome). Same list shown on the case page.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results, 1-10 (default 5) | |
| case_id | Yes | The numeric case id |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds behavioral context beyond annotations by clarifying the ranking is based on allegations and never on outcome, and that it mirrors a list on the case page. This is sufficient for a safe read operation, though rate limits or auth requirements are not mentioned (acceptable given 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?
The description is two sentences, concise and front-loaded with the core purpose. Every phrase adds value: 'most similar decided cases', 'ranked by how alike the ALLEGATIONS read (never by outcome)', and 'Same list shown on the case page'. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params, no output schema, annotations present), the description adequately covers the tool's behavior and context. It could be enhanced by briefly mentioning the output format (e.g., list of case IDs and similarity scores), but it is sufficient for a ranked list tool that mirrors a known UI element.
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 100%, with both 'case_id' and 'limit' already described clearly in the schema. The description adds no additional parameter information (e.g., format, defaults beyond schema). Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the most similar decided cases to a given case, ranked by allegation similarity (not outcome), and notes it's the same list shown on the case page. This provides a specific verb-resource relationship and distinguishes it from outcome-based or search tools among siblings.
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 for finding cases with similar allegations, but does not explicitly state when to use this tool versus alternatives (e.g., search_cases, get_case) or provide exclusions. The mention of 'never by outcome' hints at differentiation, but no sibling names or when-not conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
