Skip to main content
Glama

La Query

la_query
Read-onlyIdempotent

Run a raw SoQL query against any Los Angeles open-data resource (data.lacity.org) by its Socrata id (8-char like "2nrs-mtv8"). Full SoQL: where/select/group/order/limit/offset. Use la_datasets to find a resource id, or la_recent for the common ones.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
groupNoSoQL $group (e.g. "crm_cd_desc").
limitNoMax rows (default 100, max 5000).
orderNoSoQL $order (e.g. "date_occ DESC").
whereNoSoQL $where filter (e.g. "area_name='Central'").
offsetNoRow offset for paging.
selectNoSoQL $select (e.g. "crm_cd_desc, count(*)").
_apiKeyNoOptional — your own Socrata app token for higher rate limits. Omit to use the keyless endpoint.
resource_idYesSocrata resource id, e.g. "2nrs-mtv8" (crime data).

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • addedInput schema / examples
      Added value: +[
      +  {
      +    "_apiKey": "your-data-la-api-key",
      +    "limit": 100,
      +    "resource_id": "2nrs-mtv8",
      +    "where": "crm_cd_desc='BURGLARY'"
      +  },
      +  {
      +    "_apiKey": "your-data-la-api-key",
      +    "group": "crm_cd_desc",
      +    "limit": 20,
      +    "order": "count(*) DESC",
      +    "resource_id": "2nrs-mtv8",
      +    "select": "crm_cd_desc, count(*)"
      +  }
      +]
  2. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint true, and destructiveHint false. The description adds context about API key usage for higher rate limits and keyless fallback, which aligns with annotations and provides useful behavioral insight without contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short, front-loaded with the main purpose, and includes all necessary details in a structured way. Every sentence serves a purpose, with no redundancy or wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Even without an output schema, the description provides complete context: parameter explanations, usage with examples, sibling references for dataset discovery, and the full SoQL clause set. It is fully sufficient for an agent to use this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds meaning by explaining the 8-character Socrata ID format, default and max limit, and the optional _apiKey purpose. Examples further clarify usage, adding value beyond the schema.

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 it runs raw SoQL queries against LA open-data resources by Socrata ID. It distinguishes itself from sibling tools la_datasets and la_recent by referencing them for finding resource IDs, making the purpose specific and differentiated.

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

Usage Guidelines5/5

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

The description explicitly says to use la_datasets or la_recent for finding resource IDs, providing clear alternatives. It also includes SoQL usage details (where/select/group/order/limit/offset), giving a comprehensive guide on when and how to use this tool.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation3/5

Many tools have closely related or overlapping purposes: ask_pipeworx, ask_pipeworx_beta (currently identical), and ask_pipeworx_grounded all route to the same underlying toolset, while discover_tools and suggest_questions both help agents discover capabilities. The polymarket_* family also has several opportunity-scanning tools with subtle differences, though detailed descriptions help clarify.

Naming Consistency3/5

Names are mostly snake_case but follow mixed patterns: verb-first (ask_pipeworx, validate_claim), noun-first (entity_profile, bet_research, la_recent), and bare verbs (remember, forget, unsubscribe). The prefix groups (la_, pipeworx_, polymarket_) show some consistency, but there is no uniform verb_noun convention.

Tool Count2/5

34 tools is well into the 'too many' range for a single server. The surface bundles several distinct domains—structured data querying, prediction markets, LA open data, memory, subscriptions, and npm scanning—making it feel like a kitchen sink rather than a focused toolset.

Completeness4/5

Within each bundled sub-domain, coverage is strong: query/grounded/research/entity-profile/compare/validate covers data workflows; polymarket tools include research, edge scan, arbitrage, fill-risk, and cross-venue spread; LA data has search/query/recent; memory and subscription lifecycles are fully CRUD. Minor gaps exist (e.g., no way to browse LA dataset attributes beyond search), but no major dead ends.