Search 30,000+ decided U.S. security-clearance (DOHA) decisions: cases, outcomes, statistics, and timelines, with a citable link for every answer. CASE is the searchable public record of DOHA industrial security-clearance decisions from 1996 to the present, refreshed nightly.
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.2/5 across 7 of 7 tools scored.
Each tool targets a distinct function: searching, retrieving a specific case, finding similar cases, and four different statistical analyses (overall, candor-related, conduct recency, and timeline). No two tools overlap in purpose.
All tool names follow a clear verb_noun pattern: get_ for retrieval, search_ for searching, similar_ for similarity. The verbs vary appropriately with the action, and snake_case is used consistently.
Seven tools is well within the ideal range for a search-and-analytics server. Each tool covers a necessary capability without redundancy or bloat.
The tool set covers the full workflow: comprehensive searching (search_cases), detailed case retrieval (get_case), similarity exploration (similar_cases), and four distinct statistical views (candor, conduct recency, overall statistics, timelines). No significant gaps are apparent for the stated 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?
Given annotations already declare readOnlyHint=true and destructiveHint=false, the description adds value by stating 'Descriptive, never a prediction' and 'Counts and denominators throughout,' which inform the user about the nature and format of the output beyond what the annotations provide.
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 concise and well-structured, using a single sentence with internal lists to enumerate the breakdowns, followed by a terse caveat. Every phrase contributes to understanding the tool's purpose and output, 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?
Despite lacking an output schema, the description fully captures the tool's scope, the specific categories of outcomes, and the inclusion of counts and denominators. It also notes the descriptive nature, making the tool's functionality clear and complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%, so the description does not need to compensate for missing parameter documentation. The baseline of 4 for no-parameter tools applies, as the description adds no parameter-specific semantics but also doesn't need to.
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 resolution statistics for cases with candor allegations, specifying breakdowns such as favorable rate with vs without allegation, deliberate falsification vs rebuttal, and correction before confrontation. This distinguishes it from sibling tools like get_case and get_statistics by focusing on a specialized analytic scope.
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?
It clarifies the tool is descriptive, not predictive, indicating it should be used for historical outcome rates rather than forecasting. However, it does not explicitly name alternative tools or state when not to use it beyond the prediction caveat, so it falls short of a full 5.
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 declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds that the case is 'decided' and lists return fields, but does not disclose error behavior, auth requirements, or other behavioral traits. It provides some context beyond annotations but not rich detail.
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 tight sentences. The first delivers the core purpose and return details; the second gives a direct usage hint. No filler or repetition, with the key action 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 single-parameter fetch tool with no output schema, the description provides a thorough list of return contents (allegations, findings, outcome, judge, representation, appeal history) and the required input source. It is complete enough for an agent to select and call the tool correctly, though it omits edge-case behavior.
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 already describes case_id as 'The numeric case id from search_cases' (100% coverage). The description repeats this instruction ('Use case_id from search_cases') but adds no new meaning, so the baseline 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 opens with 'Fetch one decided DOHA case in full', which clearly identifies the verb (fetch), resource (one DOHA case), and scope (full, decided). The colon list enumerates the content, making it distinct from siblings like search_cases (which finds cases) and similar_cases (which finds related 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?
It explicitly instructs 'Use case_id from search_cases', establishing a prerequisite and workflow. It does not explicitly exclude alternatives or mention when not to use it, but the need for a case_id makes the intended usage clear.
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 declare read-only and non-destructive. The description adds the measurement source ('dates stated in the decisions'), the output format (median years, counts), and the crucial caveat that it is descriptive rather than predictive—valuable context 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?
Three concise sentences: the first states the metric, the second the output, and the third the non-predictive caveat. Every sentence earns its place, and the main purpose is 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?
Given a single optional parameter, no output schema, and a read-only analytical tool, the description covers the calculation basis, categories, output summary, and non-predictive nature. It is sufficiently complete for an agent to invoke and interpret the tool.
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 sole parameter 'guideline' is fully documented in the schema with its letter-to-category mapping, and schema coverage is 100%. The description adds no further parameter detail, so a baseline 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 computes the time between most recent conduct and decision for specific incident-type concerns, reporting median years by decision outcome. It is specific and not a tautology, and the 'never a prediction' caveat further clarifies its analytic role.
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?
It specifies the exact incident-type scope and the boundary that it is descriptive, not predictive, which implies when to use it. However, it does not explicitly name alternative tools or exclusions beyond the prediction caveat.
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 declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context about the population scope ('decided hearing-level DOHA cases') and output characteristic ('always with sample sizes'), which goes beyond the structured fields without contradicting them.
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 deliver the essential purpose, scope, grouping, and sample-size behavior. There is no filler or repetition, and the front-loaded verb 'statistics' immediately conveys the tool's function.
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 description covers the core scope and grouping, offering a reference to the Insights page for population rules, and hints at output via sample sizes. However, it does not mention the year range parameters, output structure, or behavior for missing optional parameters, and there is no output schema to fill these gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the description clarifies the 'by' parameter by mentioning grouping by year or guideline, but the year_from and year_to parameters are completely undocumented in both schema and description. This leaves the date range filtering ambiguous, and the description does not compensate for the gap.
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 'grant/denial statistics' over a specific case population ('decided hearing-level DOHA cases'), with grouping options ('by year or by guideline') and a guaranteed trait ('always with sample sizes'). This distinguishes it from sibling tools focused on individual cases or other outcome types.
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?
Usage is implied for aggregate statistics needs, and the reference to the site's Insights page provides a population-rule context. However, there is no explicit exclusion such as 'for individual case details, use get_case' or other alternative comparisons, so guidance remains implicit.
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, covering safety. The description adds behavioral nuance by explaining that metrics are derived 'from dates stated in the decisions themselves' and that medians are computed. This provides value beyond annotations without contradicting them.
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 exceptionally concise: two short sentences that front-load the core purpose and include all necessary information. There is no fluff or repetition of schema details. Every phrase 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?
With no output schema, the description clearly states what the tool returns (median days). It covers the key aspects: what is measured, from which dates, and optional year filtering. Given the tool's simplicity and good annotation coverage, the description is sufficiently complete for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'year' with a description 'Optional decision year to scope to'. The tool description repeats this in prose ('Optionally scoped to one decision year'). Since schema coverage is 100%, the description adds no new semantic information about the parameter, so the 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's purpose: 'Measured DOHA timelines: median days from Statement of Reasons to hearing and to decision'. This specifies the verb (measured/calculates), the resource (DOHA timelines), and the exact metrics (median days). It distinguishes itself from sibling tools like 'get_statistics' or 'similar_cases' by focusing specifically on DOHA timeline computations.
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 provides clear usage context: it is for analyzing DOHA timelines and optionally scoping to a decision year. While it does not explicitly name alternative tools, the 'Optionally scoped to one decision year' implies when this tool would be relevant (year-specific queries). This meets the 'clear context, no exclusions' criterion.
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 already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds valuable behavioral details beyond annotations: the dataset size, time range, and the specific fields returned (outcome, date, guidelines, citable URL), which helps the agent understand what to expect.
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, immediately states the core purpose in the first sentence, and provides return-value details in the second. Every word earns its place with no redundant or filler content.
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 has no output schema, so the description must explain return values, and it does: outcome, date, guidelines, and citable URL. Combined with 100% schema coverage and read-only annotations, the description fully covers the tool's behavior for a search operation, including its scope and result composition.
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%, so the schema fully documents all 7 parameters. The description's mention of 'Full-text query plus filters' is a high-level summary that does not add meaning beyond what the parameter descriptions already provide. Baseline 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 action ('Search'), the resource ('30,000+ decided public DOHA security-clearance decisions'), and scope ('1996 to present'). It also distinguishes itself from siblings like get_case or similar_cases by emphasizing full-text search across decisions.
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 conveys a clear context for using this tool: full-text querying with filters across a large decision corpus. It does not explicitly name alternatives or exclusion criteria, but the usage context is unambiguous enough for an agent to select it for search tasks.
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 establish read-only and non-destructive behavior. The description adds useful behavioral nuance: ranking is based on how allegations read, not outcome, and the output mirrors the case page's similar-cases list. No contradiction 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?
Two tightly written sentences with no filler or repetition of schema details. The key qualifier ('never by outcome') is included without wasted words, making the description easy to scan and understand.
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 list tool, the description provides sufficient information: what it returns, how results are ranked, and where the same list appears. No output schema exists, but the description's 'most similar decided cases' conveys the expected result adequately.
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?
Both parameters (case_id and limit) are fully described in the input schema, including default and range. The tool description adds no extra parameter semantics beyond what the schema already provides, so a baseline 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 identifies the tool's function: retrieve the most similar decided cases for a given case, ranked by allegation similarity rather than outcome. This distinguishes it from siblings like get_case and search_cases, and the 'never by outcome' qualifier removes ambiguity.
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 'same list shown on the case page' provides practical context for when this tool is appropriate. The explicit 'never by outcome' serves as an implicit exclusion for outcome-based similarity needs, though it does not name alternative tools for that purpose.
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!
