de en es ja ko ru zh

us-gov-data-mcp

Name: us-gov-data-mcp
Author: groundtruthtools

by groundtruthtools

Overview Schema Source Related Servers Discussions Admin

Python

Remote

us-gov-data-mcp

Un servidor MCP para datos del gobierno de EE. UU. Pregunta a tu asistente de IA qué contratos federales están por expirar, o qué empresas públicas tuvieron más ingresos el año pasado — y obtén respuestas que puedes verificar contra los propios registros del gobierno.

Construido sobre la API USAspending del Tesoro de EE. UU. y los datos EDGAR XBRL de la SEC. Sin scraping, sin clave de API, sin cuenta, sin datos personales.

Por qué existe esto

Ambas fuentes publican todo y permiten consultar casi nada.

usaspending.gov no permite buscar por fecha de fin de contrato. Pero cuando termina el periodo de ejecución de un contrato federal, el trabajo normalmente tiene que volver a licitarse — y esas relicitaciones son las oportunidades de mayor probabilidad en la contratación pública, visibles en datos públicos meses antes de que aparezca cualquier solicitud.

sec.gov sirve los informes de una empresa a la vez. No hay forma en el sitio de preguntar qué empresas públicas tuvieron ingresos superiores a 100 mil millones de dólares, o cuáles tienen más efectivo. La API frames de la SEC puede responder eso para los ~5.800 declarantes en una sola llamada, si ya conoces la etiqueta XBRL y el formato del periodo.

Este servidor responde a las preguntas que esos sitios no pueden.

Related MCP server: sec-edgar-mcp

Cuatro herramientas

`find_expiring_contracts` — relicitaciones

Contratos federales próximos a relicitarse, con el adjudicatario actual y los días restantes. expiring_after_days establece tu tiempo de preparación de la oferta, porque un contrato que termina la semana que viene es inútil para prepararse.

{
  "days_until_expiry": 120,
  "recipient": "PERATON ENTERPRISE SOLUTIONS LLC",
  "amount_usd": 682369225.00,
  "awarding_agency": "General Services Administration",
  "verify_url": "https://www.usaspending.gov/award/..."
}

`search_federal_contracts`

Contratos adjudicados por agencia, palabra clave, fecha o importe en dólares. Quién se está adjudicando el trabajo federal, en qué gasta una agencia, el historial de un competidor.

`screen_public_companies`

Clasifica todas las empresas públicas de EE. UU. por cualquier métrica financiera declarada.

"¿Qué empresas tuvieron ingresos superiores a 200 mil millones de dólares en 2023?"

{ "company": "Walmart Inc.", "value": 648125000000, "unit": "USD",
  "period_end": "2023-12-31", "period_type": "annual",
  "verify_url": "https://www.sec.gov/Archives/edgar/data/104169/..." }

`company_financial_history`

El historial declarado de una empresa para una métrica — ingresos, beneficio neto, activos, flujo de caja — deduplicado, con el tipo de formulario y la fecha de presentación en cada registro.

Todo es verificable

Cada registro lleva un verify_url al documento gubernamental del que procede. Ábrelo y compara.

Eso importa sobre todo con una IA en el circuito: cuando un asistente informa de una cifra en dólares, deberías poder comprobarla contra la fuente en lugar de confiar en la cadena. Si un valor discrepa alguna vez del registro oficial, eso es un error — por favor, abre un issue.

Tres trampas que esto maneja por ti

Los datos brutos de la SEC inducen a error de tres formas concretas, cada una silenciosa — obtienes un número erróneo plausible, no un error.

Un 10-Q informa del trimestre y del acumulado anual con la misma fecha de fin. Comparar el beneficio neto entre informes mezcla silenciosamente una cifra de tres meses con una de nueve. Cada registro lleva period_type, y puedes filtrar por él.
El mismo dato se repite en varios informes con valores diferentes. El 10-K de este año reexpresa las cifras del año pasado. Deduplicado a un registro por periodo, ganando la presentación más reciente — el propio tratamiento de las reexpresiones por parte de la SEC.
Las empresas cambian de etiquetas XBRL con el tiempo. Microsoft presentó Revenues hasta 2010 y una etiqueta diferente después. Tomar la primera etiqueta que devuelve datos produce un historial parcial desactualizado; esto fusiona todas ellas.

Instalación

uvx --from git+https://github.com/groundtruthtools/us-gov-data-mcp us-gov-data-mcp

Claude Desktop — añade a claude_desktop_config.json:

{
  "mcpServers": {
    "us-gov-data": {
      "command": "uvx",
      "args": [
        "--from",
        "git+https://github.com/groundtruthtools/us-gov-data-mcp",
        "us-gov-data-mcp"
      ],
      "env": { "SEC_USER_AGENT": "Your Name your@email.com" }
    }
  }
}

Funciona con cualquier cliente MCP: Claude Desktop, Claude Code, Cursor, VS Code.

Vale la pena configurar SEC_USER_AGENT. La política de acceso justo de la SEC exige un User-Agent que contenga una dirección de contacto, y las solicitudes sin uno reciben un 403. Se incluye un valor por defecto para que las herramientas funcionen sin configuración, pero identificarte es lo correcto y te mantiene fuera de una identidad compartida.

Una peculiaridad, aprendida por las malas: no pongas una URL en esa cadena. La SEC devuelve 403 para cualquier User-Agent que contenga una. Tu Nombre tu@email.com funciona; añadir github.com/... no.

Todavía no está en PyPI, así que instala desde el repositorio. Cuando llegue allí, esto se convierte en un simple uvx us-gov-data-mcp.

Límites honestos

Contratos: adjudicados, no solicitudes abiertas. Para licitaciones publicadas, usa SAM.gov.
Contratos: solo federales, sin datos anteriores al año fiscal 2008.
La búsqueda de relicitaciones cubre contratos con actividad en el último año, porque USAspending limita la profundidad de paginación de los resultados. Un contrato inactivo durante mucho tiempo puede no aparecer, y una búsqueda demasiado amplia lo dice en lugar de devolver una lista vacía con falsa seguridad.
SEC: la cobertura XBRL comienza alrededor de 2009, y solo cubre conceptos que las empresas etiquetaron realmente. Los declarantes más pequeños etiquetan menos.
Informa; no calcula. Sin ratios, tasas de crecimiento ni métricas derivadas — eso sería nuestra aritmética, no la presentación, y no podrías verificarlo contra la fuente.
No es asesoramiento de inversión. Es una herramienta de reformateo de datos.

También en Apify

La misma lógica funciona como herramientas alojadas, sin necesidad de instalación:

Fuentes de datos y licencia

Contratos: USAspending.gov, Departamento del Tesoro de EE. UU., publicado bajo la DATA Act. Datos financieros: SEC EDGAR, Comisión de Bolsa y Valores de EE. UU. Ambos de dominio público. Código: MIT.

Available Tools

4 tools

company_financial_historyA

One company's reported history of a financial metric.

Deduplicated to one record per period, taking the most recent filing -- this year's 10-K restates last year's figures, so raw SEC data repeats periods with different values.

Every record carries the form type, filing date, and a verify_url.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many periods to return, 1-200.
`metric`	No	revenue, net_income, assets, cash, operating_cash_flow, eps_diluted, and others. A raw XBRL tag also works.	revenue
`company`	Yes	Ticker like AAPL, or a CIK number.
`period_type`	No	annual gives one figure per fiscal year; quarterly gives three-month figures. Use this -- a 10-Q reports both the quarter AND the year-to-date with the same end date, so 'any' mixes 3-month and 9-month numbers.	annual

TDQS

A3.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Without annotations, the description carries the transparency burden. It discloses two key behaviors: deduplication to the most recent filing per period, and the inclusion of form type, filing date, and verify_url in each record. This is solid but does not mention potential errors, rate limits, or data ordering.

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 succinct, with three short paragraphs that directly convey purpose, deduplication logic, and record contents. No redundant or vague phrasing.

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 is no output schema, the description adequately explains what each record contains (form type, filing date, verify_url) and the deduplication rule. It lacks details on sorting, error handling, or metric value units, but the core context is covered.

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?

All four parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no new parameter-specific meaning beyond what the schema already states; it only reinforces the single-company scope implicitly via 'One company'.

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: retrieving a single company's reported history of a financial metric. It is distinct from sibling tools (e.g., search_federal_contracts) by focusing on company financials, and the verb+resource structure is specific.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not provide explicit guidance on when to use this tool over alternatives. It implies single-company scope but never states conditions like 'use when you need historical financial data' or contrasts with sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_expiring_contractsA

Find federal contracts expiring soon -- recompete opportunities.

When a federal contract's period of performance ends, the work usually has to be re-competed, and the incumbent is beatable. These are the highest-probability opportunities in government contracting, visible in public data months before any solicitation is published.

Each result includes days_until_expiry and the current incumbent.

Note: usaspending.gov itself cannot filter by end date. This walks the end-date-sorted results to find the window, so it takes a few seconds.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many contracts to return, 1-100.
`keyword`	No	Free-text search across descriptions and recipients.
`agencies`	No	Awarding agency names to restrict to.
`min_amount`	No	Only contracts at or above this dollar amount. Strongly recommended: it narrows the search and makes it faster.
`expiring_after_days`	No	Skip contracts ending sooner than this. A contract ending next week is too late to bid on; 120 is typical lead time.
`expiring_within_days`	No	Return contracts whose period of performance ends within this many days. 365 is a typical planning horizon.

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses that each result includes days_until_expiry and the incumbent, that usaspending.gov cannot filter by end date, and that the tool walks end-date-sorted results and takes a few seconds. It also signals a read-only operation through 'Find'.

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 about 90 words, front-loaded with the core purpose, then provides market context, result fields, and a performance note in separate short paragraphs. Every sentence adds useful context for selection and expectation-setting.

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 has 6 optional parameters and no output schema, but the description names the key result fields (days_until_expiry, current incumbent) and explains latency and data-source constraints. It is complete enough for a read-only search tool with richly documented params, though a full result-shape list would be even safer.

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 each parameter already well-documented including defaults, ranges, and intent. The description reinforces the 'window' concept and output fields, but does not need to add parameter-level detail.

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 'Find federal contracts expiring soon' which clearly specifies the resource (expiring federal contracts) and action (find). The mention of 'recompete opportunities' distinguishes this from the general sibling search_federal_contracts by emphasizing the specific use case.

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 strong context: federal contracts whose performance period ends must usually be re-competed, and incumbents are beatable. This explains why an agent would choose this tool, though it does not explicitly name alternative tools or state when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

screen_public_companiesA

Rank every US public company by a financial metric.

Answers questions sec.gov structurally cannot: which companies had revenue over $100 billion last year, which hold the most cash, which reported the largest losses. EDGAR serves filings one company at a time; this compares all of them at once.

Every record carries a verify_url to the filing the figure came from.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	How many companies to return, 1-200.
`order`	No	desc or asc.	desc
`metric`	No	revenue, net_income, assets, liabilities, equity, cash, operating_income, gross_profit, eps_diluted, operating_cash_flow, capex, long_term_debt, inventory, goodwill, rd_expense, shares_outstanding, and more. A raw XBRL tag such as 'Revenues' also works.	revenue
`period`	No	Calendar year like CY2024, or a quarter like CY2024Q1. Balance-sheet metrics are adjusted automatically.	CY2024
`max_value`	No	Only companies at or below this figure.
`min_value`	No	Only companies at or above this figure. Negative values are legal -- losses are real figures.
`period_type`	No	Filter by reporting period length: any, quarterly, half_year, nine_month, annual, instant.	any

TDQS

A4.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses a key behavioral trait: 'Every record carries a verify_url to the filing the figure came from.' It also establishes the scope (all US public companies) and implies read-only screening. It does not mention rate limits or error handling, but for a read-oriented tool these are not critical. The description adds meaningful context beyond what annotations would provide.

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: the first sentence states the purpose, the second paragraph gives concrete use cases, and the third adds one valuable detail (verify_url). It is front-loaded and every sentence earns its place. No wasted words or repetition of schema information.

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 (7 params, no output schema), the description is fairly complete. It explains the tool's purpose, gives examples, and hints at output structure ('Every record carries a verify_url'). It doesn't detail all return fields, but that might be implied by the metric and ranking. The description is adequate for an agent to understand when and what to expect.

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 schema covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add extra parameter semantics beyond what's already in the schema. The examples like 'revenue over $100 billion' reiterate the metric and period parameters but do not add new meaning. Therefore, it does not exceed the baseline.

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: 'Rank every US public company by a financial metric.' This is a specific verb+resource. It also distinguishes from siblings by emphasizing cross-company comparisons ('this compares all of them at once') and contrasts with SEC.gov/EDGAR. This differentiates it from company_financial_history, which likely focuses on individual company data.

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 gives clear context on when to use it: 'Answers questions sec.gov structurally cannot: which companies had revenue over $100 billion last year...' It implies this is for cross-company screening. However, it does not explicitly mention when not to use it or name alternatives like company_financial_history for single-company history, so it stops short of explicit exclusion. This earns a 4, not a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_federal_contractsA

Search awarded US federal government contracts.

Returns contracts the government has already awarded, largest dollar value first. Use this to see who is winning federal work, what an agency spends, or a specific company's contract history.

For contracts coming up for re-bid, use find_expiring_contracts instead.

ParametersJSON Schema

Name	Required	Description
`limit`	No	How many awards to return, 1-100.
`keyword`	No	Free-text search across award descriptions and recipient names, e.g. 'cybersecurity'. Omit to search all.
`agencies`	No	Awarding agency names, e.g. ['Department of Defense'].
`end_date`	No	Latest award action date, YYYY-MM-DD.
`min_amount`	No	Only awards at or above this dollar amount.
`start_date`	No	Earliest award action date, YYYY-MM-DD. No earlier than 2007-10-01.

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations supplied, the description carries the behavioral disclosure burden. It discloses that results are limited to already-awarded contracts and that they are sorted 'largest dollar value first,' which goes beyond the schema. It does not mention pagination, output fields, or rate limits, but for a search/read tool the key behavioral traits are adequately surfaced.

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: the first sentence states the tool's purpose, the second adds result ordering and use cases, and the final sentence points to an alternative. Every sentence earns its place with 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?

The tool has six optional, well-documented parameters and no output schema, so the description needs to convey scope and return behavior. It covers scope, sort order, and common use cases, but it does not enumerate the contract fields returned. Still, for selection and invocation, the description is sufficiently complete.

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 already provides thorough descriptions for all six parameters (e.g., 'Free-text search across award descriptions and recipient names'), so the description does not need to repeat them. It adds minimal parameter-level value beyond schema, but the schema coverage is 100%, meeting the baseline.

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 'Search awarded US federal government contracts' and immediately distinguishes it from expiring-contract searches with 'Use this to see who is winning federal work.' It names specific use cases and references the sibling find_expiring_contracts, so an agent can tell this tool from alternatives.

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?

Explicit guidance is given on when to use this tool: for seeing who is winning federal work, what an agency spends, or a company's contract history. It also gives an explicit exclusion: 'For contracts coming up for re-bid, use find_expiring_contracts instead.' This clearly orients selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv1.0.0Aug 21, 2026
- First observedcompany_financial_history
- First observedfind_expiring_contracts
- First observedscreen_public_companies
- First observedsearch_federal_contracts

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-08-21 00:31 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: search_federal_contracts finds awarded contracts, find_expiring_contracts identifies expiring ones, screen_public_companies ranks companies by metrics, and company_financial_history retrieves a single company's historical financials. No overlapping functionality exists between the four tools.

Naming Consistency2/5

The naming pattern is inconsistent. The first three tools use a verb-noun structure (search_, find_, screen_), but the fourth uses a noun-noun structure (company_financial_history). Additionally, the verbs 'search', 'find', and 'screen' are near-synonyms, which could confuse users about their exact purposes. The pattern is not uniform across the set.

Tool Count4/5

With only 4 tools, the server is reasonably scoped for its niche of government contracts and public company financials. It is slightly on the low end but within the acceptable 3–15 range, and each tool serves a distinct query need without unnecessary bloat.

Completeness4/5

The tool surface covers the primary queries for the domain: searching awarded contracts, finding expiring ones, screening companies by financial metrics, and retrieving a company's financial history. There are minor gaps (e.g., no tool for detailed contract metadata or company fundamentals beyond history), but agents can accomplish core tasks without dead ends.

Maintenance

ActivitySlowing

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

TangoOAuth
dev.tango
MCP access to the U.S. federal procurement graph: contracts, opportunities, entities, and more.
Government Data Open Data
2
SignalTender B2B, GovCon & LegalTech MCP Server A
io.github.aarbchen
B2B, GovCon & LegalTech MCP server for live RFPs, contract parsing, compliance & proposal tools.
Legal & Compliance Government Data
131
secedgar-mcp-server A
io.github.cyanheads
Query SEC EDGAR filings, XBRL financials, and company data via MCP. STDIO or Streamable HTTP.
Finance Government Data Open Data
16210
Usaspending A
io.github.pipeworx-io
USAspending MCP — Federal spending data from USAspending.gov API
Government Data Open Data Search
472

Related MCP Servers

SEC EDGAR MCP
Finance Government Data
stefanoamorelli
A
license
C
quality
B
maintenance
MCP server for accessing SEC EDGAR filings. Connects AI assistants to company filings, financial statements, and insider trading data with exact numeric precision.
Updated 17 days ago (2026-10-03 09:11 UTC)
21
1,051 PyPI
373
AGPL 3.0
sec-edgar-mcp
Finance Government Data Open Data
guptaprakhariitr
A
license
Not graded
quality
D
maintenance
Hosted MCP server that gives AI agents real-time access to SEC EDGAR filings search, 10-K/8-K reading, XBRL financial facts, and insider-trade (Form 4) alerts.
Updated 4 months ago (2026-06-11 08:39 UTC)
13 npm
1
MIT
filed-mcp-server
Government Data Open Data Search
mgrantley
F
license
A
quality
D
maintenance
An MCP server that gives AI agents access to US business entity data, enabling searches across 9 state registries, SEC EDGAR filings, federal contracts, and lobbying disclosures.
Updated 7 months ago (2026-03-20 02:50 UTC)
6
1
-
USAspending MCP Server
Government Data Open Data
haydentbs
A
license
A
quality
D
maintenance
Read-only MCP server for exploring US federal spending data via the USAspending.gov API, enabling natural language queries on awards, agencies, recipients, and spending trends.
Updated 4 months ago (2026-06-19 08:40 UTC)
12
MIT

us-gov-data-mcp

Por qué existe esto

Cuatro herramientas

find_expiring_contracts — relicitaciones

search_federal_contracts

screen_public_companies

company_financial_history

Todo es verificable

Tres trampas que esto maneja por ti

Instalación

Límites honestos

También en Apify

Fuentes de datos y licencia

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

`find_expiring_contracts` — relicitaciones

`search_federal_contracts`

`screen_public_companies`

`company_financial_history`