Ten source-bound government-record evidence tools plus four run helpers for property, healthcare integrity, regulated facilities, Norway company evidence, and cross-market routing. Public metadata discovery; caller-owned Apify token required for execution.
Abort a caller-owned Actor run that is starting or running. Terminal runs are unchanged.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | Actor run ID to abort. | |
| gracefully | No | Request a graceful abort with the provider timeout. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds valuable behavioral context by specifying that only caller-owned, non-terminal runs are affected and that terminal runs remain unchanged. No contradiction with annotations is present.
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 focused sentence with no filler. It front-loads the action and resource, then adds the key state and ownership constraints, earning every word.
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 destructive, idempotent annotations and two fully documented parameters, the description captures the essential conditions and scope. A note about response behavior or error cases would add completeness, but nothing critical is missing 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 description coverage is 100%, with both runId and gracefully documented in the input schema. The description itself adds little parameter-level meaning, but the schema fully covers the parameters, so the baseline of 3 applies.
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 uses a specific verb ('Abort'), a clear resource ('caller-owned Actor run'), and precise conditions ('starting or running'). It also distinguishes behavior for terminal runs, making the purpose unambiguous even alongside sibling tools like get-actor-run.
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 clearly implies when to use the tool: for a caller-owned Actor run that is still starting or running. It also excludes terminal runs, which is a helpful boundary. It does not explicitly name alternative tools for terminal runs or checking status, but the guidance is adequate for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for routing a supported U.S. property, India company or supplier, restricted-party, EPA facility, or rights-first China-facing intake task into one minimized, receipt-bound packet. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| task | Yes | ||
| purpose | No | ||
| subject | Yes | ||
| evidence | No | ||
| retentionDays | No | ||
| batchReference | No | ||
| transactionGate | No | ||
| previousReceiptHash | No | ||
| screenRestrictedParties | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
It discloses behavioral traits beyond the annotations: starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, returns at most 1,000 source-linked rows, and does not modify government records. These are operationally significant details that the annotations do not 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 front-loaded with the primary routing purpose, followed by side effects and limits. The first sentence is dense but contains no filler. It earns a high score, though it could be slightly clearer with a structured list of task categories.
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 9 parameters, nested objects, and no output schema, the description omits essential invocation context: how to structure subject identifiers, what 'evidence' means, how receipts work, and what the returned packet looks like. It covers side effects well but not enough for correct use.
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?
With 0% schema description coverage and 9 parameters, the description needed to explain parameter meaning but only loosely maps to the task enum via phrases like 'U.S. property' and 'India company'. It gives no guidance on the required subject object, the evidence array, retentionDays, previousReceiptHash, transactionGate, or screenRestrictedParties.
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 a routing gateway with a specific verb ('Use for routing') and enumerates the supported domains: U.S. property, India company/supplier, restricted-party, EPA, and China-facing intake. It also states the output concept ('one minimized, receipt-bound packet'), which distinguishes it from the sibling direct-evidence tools.
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 gives clear context for when to use this tool: routing supported evidence tasks into a packet. It does not explicitly say when not to use it or name alternatives like the sibling specialized tools, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for a bounded EPA ECHO facility query that preserves published identity, compliance, inspection, and enforcement evidence while keeping environmental safety UNKNOWN. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| zip | No | ||
| city | No | ||
| state | No | ||
| facilityId | No | Exact 12-digit Facility Registry Service ID, for example 110000367567. | |
| facilityName | No | Published facility name. Add location fields to reduce ambiguity. | |
| maxCandidates | No | ||
| nameMatchMode | No | Exact is the responsible default. Contains is discovery-only and may require review. | exact |
| streetAddress | No | Full or partial published street address. Address-only searches also require city, state, or ZIP. | |
| includeProgramDetails | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond what annotations provide, it discloses concrete side effects: launching a bound Apify Actor with the caller's token, possible Apify usage cost, a 60-second wait, a 1,000-row cap, and no modification of government records. This gives the agent essential operational context for a call that is not purely read-only despite not altering government data.
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 compact: two sentences front-load the purpose and then list the invocation behaviors that matter. The phrase 'keeping environmental safety UNKNOWN' is unexplained jargon, which keeps it from being fully crisp.
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?
It covers cost, duration, and output-size expectations, which is valuable for an external Actor invocation. But with nine optional parameters, no required field, and no output schema, the description alone is not enough to tell an agent exactly how to construct a query or interpret the returned evidence.
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 only 44%, and the tool description adds no parameter-specific guidance. It mentions boundedness and row limits but does not clarify how to choose among zip, city, state, facility name, address, or maxCandidates, leaving most param semantics to 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 states a specific resource and action: a bounded EPA ECHO facility query that preserves identity, compliance, inspection, and enforcement evidence. It is more specific than the title alone but does not explicitly contrast this with sibling tools such as the evidence gateway, so it stops short of full differentiation.
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 gives a clear use-case signal ('Use for a bounded EPA ECHO facility query') and warns about Apify usage consumption, which helps an agent decide whether the cost is acceptable. However, it does not name any sibling or state when not to use this tool, so the routing guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for Florida statewide DBPR vacation-rental and lodging-license evidence. For municipal STR permits use str-permit-registry; for code violations use property-violations. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | Filter by property location city (e.g. Kissimmee, Orlando, Destin). Leave empty for all. | |
| county | No | Filter to one Florida county by property location (e.g. Orange, Osceola, Dade, Monroe, St. Johns). Leave empty for statewide. | |
| status | No | Current = up to date with DBPR; Delinquent = license not renewed on time (expiry date has passed). | all |
| maxRecords | No | Cap total records returned (statewide is ~174k). | |
| licenseType | No | DBPR licenses vacation rentals as Condos (type 2006) or Dwellings (type 2007, incl. single-family homes & townhouses). | all |
| nameContains | No | Case-insensitive substring match on the business name or licensee name. | |
| proxyConfiguration | No | The state site blocks plain datacenter traffic; Apify Proxy is used by default. Switch to residential if datacenter IPs get blocked. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses operational behavior beyond annotations: it starts an Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, caps results at 1,000 rows, and does not modify government records. This is important side-effect context not present in the 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 front-loaded sentences: purpose, sibling routing, then operational behavior. Every sentence earns its place, and no schema field descriptions are redundantly repeated.
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 selection context, side effects, timeouts, result caps, and non-destructiveness, which is strong for a 7-parameter tool with no output schema. It stops short of describing the exact output fields or pagination beyond the 1,000-row cap, leaving a minor completeness gap.
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 covers all parameters with rich descriptions, so the baseline is high. The tool description adds a meaningful global constraint absent from the schema—at most 1,000 source-linked rows returned—which affects expectations for maxRecords and overall output volume.
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 a specific use case: Florida statewide DBPR vacation-rental and lodging-license evidence. It explicitly names sibling tools to distinguish scope, so an agent can immediately tell this from str-permit-registry and property-violations.
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 directs the agent to use str-permit-registry for municipal STR permits and property-violations for code violations, providing clear when-to-use and when-not-to-use guidance. The main use case is also stated upfront.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use to find review candidates in the HHS-OIG LEIE by name, valid NPI, state, specialty, or exclusion type. Do not treat a candidate match as identity adjudication or use this tool for facility licensing. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without changing the source list.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | screen checks people/entities and returns evidence records; filter pulls source LEIE records with provenance. | screen |
| state | No | Two-letter state code, for example TX. | |
| enrichNpi | No | Look up matched LEIE NPIs or a caller-supplied NPI in the official CMS registry and return explainable correlation signals. NPI status is not licensure or eligibility. | |
| samApiKey | No | Caller-supplied SAM.gov public API key. Required only when includeSam is enabled; never returned in output. | |
| specialty | No | Substring match on specialty, such as NURSING, PHARMACY, or HOME HEALTH. | |
| includeSam | No | Opt in to the official GSA SAM.gov Exclusions API. Requires your own public SAM.gov API key. | |
| maxRecords | No | Caps LEIE records returned in filter mode. | |
| screenList | No | For screen mode. Each item: { "name": "JOHN SMITH" or "ACME HOME HEALTH", "npi": "1234567893" (optional valid test NPI), "state": "NC" (optional), "ref": "your-id" (optional) }. Name-only matches are normalized exact-name candidates, constrained by state when supplied, and require human review. | |
| exclusionType | No | OIG exclusion authority code, such as 1128a1 or 1128b5. | |
| maxNpiLookups | No | Caps NPPES calls per run. Remaining rows still receive LEIE results and show that enrichment was skipped. | |
| maxSamQueries | No | Caps SAM.gov calls per run to respect the official API's role-dependent rate limits. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint=false, destructiveHint=false) are enriched by the description: it discloses that the tool starts an Apify Actor, may consume Apify usage, waits up to 60 seconds, and returns a bounded result set while 'without changing the source list.' This directly addresses side effects and non‑destructive behavior beyond what the flags alone imply.
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, no filler. The purpose is front‑loaded, then constraints and side effects. Every token earns its place, and it avoids restating obvious parameter details already in the schema.
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 complex tool with 11 parameters and two modes, the description covers the essential operational context (side effects, limits, non‑destructiveness) but does not explain the distinction between screen and filter modes or the shape of the returned records. However, the schema descriptions handle those aspects thoroughly, so the description is adequate for an experienced agent.
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%, and each parameter already has a rich, explanatory description (e.g., mode, enrichNpi notes, samApiKey secrecy). The tool description only summarizes the parameter space ('by name, valid NPI, state, specialty, or exclusion type') without adding detail, so it stays at the baseline 3 for a fully‑documented 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 states a specific verb ('find review candidates') and a concrete resource ('HHS-OIG LEIE'), and lists the search dimensions (name, NPI, state, specialty, exclusion type). This clearly distinguishes it from sibling tools that query other registries (EPA, restaurant inspections, etc.) without needing to open any schemas.
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 says when to use the tool ('Use to find review candidates') and gives exclusions: 'Do not treat a candidate match as identity adjudication or use this tool for facility licensing.' It does not name an alternative sibling, but the sibling set is clearly domain‑distinct, so usage context is sufficient. Operational guidance (waits up to 60s, returns ≤1,000 rows) reinforces expected usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for cross-state childcare licensing, inspection, and deficiency research across supported states. For Texas-only operation, inspection, or deficiency filters, use texas-childcare-licensing instead. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| county | No | Filter to one county (e.g. 'Sussex', 'Oneida', 'Boulder'). Applied server-side where the state feed carries a county column; CT publishes no county so a county filter returns no CT rows. Leave empty for statewide. | |
| states | No | Which states to pull. Available: NY (16.8k facilities), NJ (4.2k), CO (4.5k), CT (16.2k + inspections), DE (1.2k + inspections & deficiencies). Leave empty for all five. | |
| licenseStatus | No | Case-insensitive substring match on the facility's license status (e.g. 'ACTIVE', 'License', 'Licensed'). Leave empty for all statuses. | |
| minDeficiencies | No | Only return facilities with at least this many cited deficiencies (compliance screening). Deficiency counts are published only by Delaware; other states have none, so this filter excludes them. | |
| maxInspectionRows | No | Cap the inspection/deficiency rows fetched per state before building the per-facility compliance lookup (leave empty to read the full feed; CT ships ~97k inspection rows). | |
| includeInspections | No | When on, fetch each state's inspection/deficiency feed and merge per-facility inspection_count and (DE) deficiency_count + top cited regulations. Turn off for a faster, licensing-only pull. Only affects CT and DE. | |
| maxRecordsPerState | No | Cap the number of facility records pulled from each state (leave empty for the full registry). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations only saying readOnlyHint=false and idempotentHint=false, the description adds important context: it 'Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.' This clearly discloses side effects, timeouts, limits, and non-destructive behavior beyond what 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 three sentences that each carry weight: purpose and distinction, sibling routing, and behavioral constraints. It is front-loaded with the most important usage signal and avoids fluff.
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 purpose, sibling differentiation, actor execution, side effects, timeout, row limit, and non-modification of records. With 7 parameters but no output schema, it could have described the response format in more detail, but the supplied context is sufficient 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 description coverage is 100%, so every parameter is already documented in the input schema. The overall description does not add parameter-level meaning beyond schema, so the baseline of 3 applies.
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 a specific verb and resource scope: 'Use for cross-state childcare licensing, inspection, and deficiency research across supported states.' It also names the sibling it is not, texas-childcare-licensing, which lets an agent distinguish these two tools without opening schemas.
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 states when to use this tool ('cross-state') and names the alternative with the selecting condition: 'For Texas-only operation, inspection, or deficiency filters, use texas-childcare-licensing instead.' This is direct routing guidance with no inference required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for exact nine-digit Norwegian organisation-number evidence or bounded company-name research from Brønnøysundregistrene. NLOD 2.0 permits commercial reuse with attribution and change disclosure, but buyer-specific privacy and lawful-basis review may still be required for personal-data-bearing records; this Actor omits roles, contacts, and street address lines and never issues a KYC, procurement, sanctions, or eligibility verdict. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| queries | Yes | One to 25 evidence queries. Prefer the exact nine-digit organisation number. A supplied name alongside an organisation number is returned as a consistency check, never as a replacement identifier. | |
| maxRecords | No | Name searches request one additional record internally so truncation is detected and disclosed. | |
| batchReference | No | Optional non-sensitive batch reference bound into the shared batch receipt. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses significant runtime behavior beyond the annotations: it starts a bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, returns at most 1,000 source-linked rows, omits roles/contacts/street addresses, and modifies no government records. This is consistent with the annotations; openWorldHint=true and readOnlyHint=false align with the external Actor execution.
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 three sentences and front-loads the core purpose, followed by licensing/privacy context and then behavioral constraints. Each sentence adds distinct value with no redundancy, though it is slightly dense.
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 that launches an external Actor and consumes usage, it covers the important contextual details: caller token, cost implication, timeout, row cap, no record modification, and a privacy caveat. It lacks an explicit output schema, but the description's 'source-linked rows' and omitted-field list give an agent adequate expectations for selecting and calling it.
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% and the nested parameter descriptions are already rich, covering purpose enums, receipt hashes, truncation detection, and name-search ambiguity. The description's 'exact nine-digit' and 'bounded' phrasing largely mirrors what the schema already states, so it adds little new parameter-level 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 names a clear resource ('Norwegian organisation-number evidence or bounded company-name research') and a specific source (Brønnøysundregistrene). It is not a tautology and is distinct from the other civicdataforge tools, though it does not explicitly name sibling alternatives.
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 opens with 'Use for exact nine-digit...' and adds clear exclusions: it 'never issues a KYC, procurement, sanctions, or eligibility verdict.' This gives an agent a solid sense of when to invoke it, even though it does not explicitly contrast it with the evidence-gateway sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for municipal building, property, and code-violation research in supported jurisdictions. Do not use for STR licensing or restaurant health inspections; choose the corresponding permit or inspection tool. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | Which city building code-enforcement / property-violation registries to pull. | |
| status | No | Return all violations, or only currently OPEN/active ones (the distress signal buyers usually want). | all |
| maxRecordsPerCity | No | Cap records per city, newest first (leave empty to pull the full registry). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations say readOnlyHint=false and openWorldHint=true, and the description explains why: it starts a bound Apify Actor with the caller's token, may consume Apify usage, and waits up to 60 seconds. It adds a meaningful non-modification guarantee without contradicting the hints.
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 sentences: usage, exclusion, and behavior. Dense but efficient, front-loaded with the main purpose.
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?
Covers side effects, limits, timeout, and non-destructiveness, but with no output schema the return shape is only sketched as 'at most 1,000 source-linked rows.' An agent still has to infer the fields returned; a 4 is appropriate.
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?
All three parameters already have detailed schema descriptions (100% coverage), so the description need not restate them. It adds context like 'source-linked rows' and the 1,000-row cap, but no per-parameter semantics 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 states a specific use ('municipal building, property, and code-violation research'), names the domain, and explicitly separates the tool from STR licensing and restaurant-inspection siblings. This is enough for an agent to know what resource it acts on, even though the verb is 'use for... research' rather than 'search'.
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?
Gives clear when-to-use conditions and an explicit do-not-use rule naming the alternatives (permit and inspection tools). It also scopes to 'supported jurisdictions,' which aligns with the cities parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for official restaurant inspection scores, violations, and facility-history research in supported jurisdictions. Do not use for general property-code violations or childcare inspections. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| since | No | Inclusive ISO date YYYY-MM-DD. | |
| until | No | Inclusive ISO date YYYY-MM-DD. | |
| cities | No | Official inspection feeds to query. Every output and run receipt discloses source age, row grain, and source status. | |
| resultContains | No | Case-insensitive substring on the jurisdiction's published result or grade. A source with no such field returns no matches; scores are never guessed into grades. | |
| socrataAppToken | No | Optional caller-owned app token for a dedicated Socrata rate-limit pool. It is sent only as X-App-Token and never returned. | |
| maxRecordsPerCity | No | Bounded newest-first query limit per jurisdiction (1-5,000). | |
| businessNameContains | No | Case-insensitive establishment-name substring. Applied server-side where supported and verified client-side for every source. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond annotations by disclosing execution traits: it 'Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.' This adds cost, timeout, row-limit, and non-mutation specifics that annotations do not cover, and it does not contradict the provided 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 three sentences, tightly written, with the purpose and exclusions front-loaded, followed by execution behavior and constraints. Every sentence earns its place; there is no fluff or repetition of schema 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?
Given the tool has 7 parameters, no output schema, and moderate complexity, the description covers the key contextual needs: purpose, exclusions, cost, timeout, row limit, and non-modification. It could have described the output structure in more detail, but 'source-linked rows' plus the schema-level promise of run receipts in the cities parameter provides sufficient context for an agent to call 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?
Schema coverage is 100%, with every parameter having a meaningful description (e.g., date patterns, defaults, enums). The tool description does not elaborate on individual parameters, but it does add overall context about row limits and non-modification. Per the rubric, with high schema coverage, the baseline is 3, and the description does not need to add per-parameter detail.
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: 'official restaurant inspection scores, violations, and facility-history research in supported jurisdictions.' It also explicitly excludes 'general property-code violations or childcare inspections,' which differentiates it from sibling tools like property-violations and childcare-licensing. This is a specific verb-resource pairing with clear boundaries.
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 gives explicit when-to-use and when-not-to-use guidance: 'Use for official restaurant inspection scores... Do not use for general property-code violations or childcare inspections.' It also clarifies the supported jurisdictions are those listed in the schema, giving agents clear selection criteria without needing to inspect siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for address, permit-ID, or jurisdiction research across 31 supported US short-term-rental permit sources. For Florida statewide DBPR lodging licenses, use fl-dbpr-vacation-rentals instead. Address mode preserves explicit evidence decisions, scope, and receipts. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| cities | No | Which of the 29 covered cities to pull. Published fields vary by city — see the README coverage table. | |
| status | No | Return all permits, or only currently-active licenses. | all |
| snapshot | No | Persist a query-scoped baseline and compare it with the prior complete run. Requires maxRecordsPerCity to be cleared; capped results are rejected so they cannot create false disappearance alerts. | |
| maxRecordsPerCity | No | Cap records per city (leave empty for the full registry). | |
| resolveJurisdiction | No | Use coordinates and Census boundaries to distinguish an incorporated city from an unincorporated county area. Disable for a faster raw-source pull. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: it discloses that invoking the tool starts an Apify Actor using the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, returns at most 1,000 rows, and does not modify government records. This covers side effects, timeout, output limits, and safety, aligning with the destructiveHint=false annotation without contradicting readOnlyHint=false.
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 compact and front-loaded with the primary purpose, then quickly covers the key alternative, mode behavior, and operational constraints. Every sentence contributes either routing, side-effect, or limit information, with no filler or repetition of schema details.
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 does not specify the structure of returned rows beyond 'source-linked,' but it does state the limit of 1,000 and that no government records are modified. The mention of 'Address mode' is slightly ambiguous since no such parameter exists, but the schema and descriptions otherwise make invocation requirements clear.
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 structured schema already documents each parameter thoroughly. The tool description adds no per-parameter detail beyond referencing 'Address mode' generically, which is not a named parameter. 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 states a specific verb and resource: 'Use for address, permit-ID, or jurisdiction research across 31 supported US short-term-rental permit sources.' It clearly differentiates itself from the Florida-specific sibling by naming fl-dbpr-vacation-rentals as the alternative.
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 instructs when to use this tool and when not to: 'For Florida statewide DBPR lodging licenses, use fl-dbpr-vacation-rentals instead.' It also frames the general intended use ('address, permit-ID, or jurisdiction research'), giving clear context for routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use for Texas-only childcare operation, inspection, and deficiency evidence. For comparable research spanning multiple supported states, use multistate-childcare-licensing instead. Starts the bound Apify Actor with the caller's APIFY_TOKEN, may consume Apify usage, waits up to 60 seconds, and returns at most 1,000 source-linked rows without modifying government records.
| Name | Required | Description | Default |
|---|---|---|---|
| county | No | Filter to one Texas county (e.g. HARRIS, DALLAS, TRAVIS). Leave empty for statewide. | |
| maxRecords | No | Cap total records (leave empty for the full registry, ~100k). | |
| operationType | No | e.g. 'Licensed Center', 'Licensed Child-Care Home', 'Listed Family Home'. Leave empty for all. | |
| minHighDeficiencies | No | Only return operations with at least this many high-severity deficiencies (compliance screening). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations, the description discloses meaningful behavioral details: it starts a bound Apify Actor, consumes Apify usage, waits up to 60 seconds, returns at most 1,000 rows, and does not modify government records. This aligns with openWorldHint and idempotentHint=false and adds concrete side-effect and timeout context.
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 with every clause earning its place: scope, sibling alternative, runtime behavior, timeout, row limit, and non-mutation. It is front-loaded with the most decision-relevant information.
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 there is no output schema, the description adequately explains what the caller gets ('at most 1,000 source-linked rows') and what the caller should know before invoking ('may consume Apify usage,' 'waits up to 60 seconds'). It is complete for selection and 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 description coverage is 100%, so the parameters are already well documented. The description adds some useful context like 'source-linked rows' and 'without modifying government records,' but it does not substantially enrich the meaning of the individual parameters beyond their existing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise scope ('Texas-only childcare operation, inspection, and deficiency evidence'), making the resource and purpose explicit. It also distinguishes itself from a sibling tool, so an agent can tell them apart immediately.
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 states when to use this tool ('Texas-only') and names the alternative for multi-state research ('use multistate-childcare-licensing instead'). This is clear routing guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read the status, storage identifiers, summary, and next step for an Actor run. A positive waitSecs value waits for a terminal state within the documented cap.
| Name | Required | Description | Default |
|---|---|---|---|
| runId | Yes | Actor run ID. | |
| waitSecs | No | Seconds to wait for a terminal state. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds meaningful wait semantics beyond the annotations: a positive waitSecs value waits for a terminal state, and a maximum cap is referenced. The read-only, idempotent, non-destructive profile is already covered by annotations, and the description is consistent with those hints.
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 with no filler. The core purpose and return fields are front-loaded, and the second sentence efficiently captures the important blocking behavior of waitSecs. 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?
For a low-complexity read tool with only two parameters and strong annotations, the description is largely complete. Since there is no output schema, enumerating the returned categories (status, storage identifiers, summary, next step) helps the agent know what to expect, though exact response structure is not detailed.
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 runId and waitSecs. The description mostly paraphrases the schema's waitSecs behavior ('waits for a terminal state') and adds only the cap reference, so it provides no substantial additional parameter 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 opens with a specific verb ('Read') and clearly identifies the resource ('Actor run') plus the exact set of returned information: status, storage identifiers, summary, and next step. It is immediately distinguishable from the sibling abort-actor-run, which is the opposite operation.
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 makes it clear this is the read-only observation tool for Actor run status, which is the right choice for polling or inspecting a run's current state and outputs. It does not explicitly say 'use abort-actor-run to cancel' or list exclusions, but the context is clear enough for a simple read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read result rows from a caller-owned Apify dataset, with bounded pagination and optional field selection.
| Name | Required | Description | Default |
|---|---|---|---|
| desc | No | ||
| omit | No | ||
| clean | No | ||
| limit | No | ||
| fields | No | ||
| offset | No | ||
| flatten | No | ||
| datasetId | Yes | Dataset ID or username~dataset-name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful context about caller ownership and bounded pagination, but it does not disclose concrete behavioral details such as pagination limits, defaults, or how field selection behaves.
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 front-loaded sentence with no filler. Every phrase adds meaning: the operation, the ownership constraint, pagination behavior, and field-selection capability.
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 8 parameters, no output schema, and minimal parameter descriptions, the description alone is not enough for an agent to invoke the tool correctly. It fails to explain return shape, pagination bounds, field selection syntax, flatten/omit/clean semantics, or default 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?
Schema description coverage is only 13%, so the description carries a heavy burden for explaining parameters. It vaguely covers pagination (limit/offset) and field selection (fields), but completely omits desc, omit, clean, and flatten, leaving seven of eight parameters effectively undocumented.
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 operation ('Read result rows') and the resource ('caller-owned Apify dataset'), which distinguishes it from sibling tools like get-key-value-store-record and get-actor-run. The phrase 'bounded pagination and optional field selection' adds concrete scope beyond the title.
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: this tool is for reading result rows from a caller-owned dataset, which implies it is not for other dataset owners or other data stores. It does not name alternative tools explicitly, but there are no close dataset siblings, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one exact record from a caller-owned Apify key-value store.
| Name | Required | Description | Default |
|---|---|---|---|
| recordKey | Yes | Exact record key. | |
| keyValueStoreId | Yes | Key-value store ID or username~store-name. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, covering the safety profile. The description adds useful context beyond annotations by specifying 'caller-owned' (an ownership/permission constraint) and 'exact record' (no pattern matching). It does not describe return format or error behavior, but the annotation coverage lowers the burden.
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, tightly worded sentence with no filler. Every element—read, exact record, caller-owned, Apify key-value store—contributes to the agent's understanding.
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 operation with only two fully documented parameters and safety annotations, the description is nearly complete. It covers ownership scope and exactness. It does not describe the response shape, but given the absence of an output schema and the tool's simplicity, this is a minor gap.
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%, so both parameters are already well documented. The description adds no additional parameter-level meaning beyond the schema, making the baseline 3 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 states a specific verb ('Read'), a specific resource ('exact record from a caller-owned Apify key-value store'), and a precise scope ('one exact record'). This clearly differentiates it from siblings like get-dataset-items, which target dataset items rather than key-value store records.
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 when to use the tool: when you need exactly one record from a key-value store you own. However, it does not explicitly mention alternatives or exclusions, such as using get-dataset-items for dataset data, so the guidance is contextual but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
abort-actor-runcivicdataforge--civicdataforge-evidence-gatewaycivicdataforge--epa-echo-facility-compliancecivicdataforge--fl-dbpr-vacation-rentalscivicdataforge--leie-exclusion-screeningcivicdataforge--multistate-childcare-licensingcivicdataforge--norway-company-evidencecivicdataforge--property-violationscivicdataforge--restaurant-inspection-scorescivicdataforge--str-permit-registrycivicdataforge--texas-childcare-licensingget-actor-runget-dataset-itemsget-key-value-store-recordClaiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such as io.github.acme/server also needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.
HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at /.well-known/glama.json on the same origin as the connector, then choose Check HTTP challenge.
DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
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
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
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!
Add one secure layer between your agents and this server.
Most domain tools are well-scoped with explicit cross-references (e.g., FL DBPR vs. STR registry, Texas vs. multistate childcare). However, the evidence-gateway overlaps with EPA, U.S. property, and other specialized tools by describing similar intake categories, creating ambiguity about when to use the router versus the domain-specific tool.
The specialized tools consistently use the civicdataforge-- prefix with descriptive noun phrases, while the generic actor tools use imperative verb_noun style. The naming is readable and predictable within each subgroup, but the mixed conventions and the awkward doubled prefix in civicdataforge--civicdataforge-evidence-gateway prevent full consistency.
Fourteen tools is reasonable for a broad government-evidence server covering many data domains plus an async run lifecycle. The count is not excessive, though the gateway and several overlapping domain-specific tools add some redundancy.
The tool set covers a wide range of evidence domains and provides complete async workflow coverage: launch queries, check run status, fetch dataset items, read KVS records, and abort runs. Minor gaps remain, such as no explicit way to enumerate supported jurisdictions or sources, and the gateway's broad categories are underspecified.