Skip to main content
Glama
srobbin

opengov-mcp-server

by srobbin

get_data

Retrieve datasets, metadata, and statistics from the Chicago Data Portal. Perform operations like data filtering, catalog searches, and site analytics using specified queries and parameters.

Instructions

[City of Chicago | Data Portal] Access data and metadata to learn more about the city and its underlying information.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
datasetIdNoDataset identifier required for the following operations: - For type=dataset-metadata: Get dataset details - For type=column-info: Get column information - For type=data-access: Specify which dataset to query (e.g., 6zsd-86xi)
domainNoOptional domain (hostname only, without protocol). Used with all operation types.
groupNoFor type=data-access only. Groups results for aggregate functions.
havingNoFor type=data-access only. Filters for grouped results, similar to where but for grouped data.
limitNoMaximum number of results to return: - For type=catalog: Limits dataset results - For type=data-access: Limits data records returned
offsetNoNumber of results to skip for pagination: - For type=catalog: Skips dataset results - For type=data-access: Skips data records for pagination
orderNoFor type=data-access only. Orders the results based on specified columns (e.g., "date DESC").
qNoFor type=data-access only. Full text search parameter for free-text searching across the dataset.
queryNoSearch or query string with different uses depending on operation type: - For type=catalog: Search query to filter datasets - For type=data-access: SoQL query string for complex data filtering
selectNoFor type=data-access only. Specifies which columns to return in the result set.
soqlQueryNoFor type=data-access only. Optional SoQL query string for filtering data. This is an alias for the query parameter and takes precedence if both are provided.
typeYesThe type of operation to perform: - catalog: List datasets with optional search - categories: List all dataset categories - tags: List all dataset tags - dataset-metadata: Get detailed metadata for a specific dataset - column-info: Get column details for a specific dataset - data-access: Access records from a dataset (with query support) - site-metrics: Get portal-wide statistics
whereNoFor type=data-access only. Filters the rows to be returned (e.g., "magnitude > 3.0").

Implementation Reference

  • Primary handler function for the 'get_data' tool. It parses the input parameters, validates requirements for certain operations, and dispatches to specialized sub-handlers based on the 'type' field (catalog, categories, tags, dataset-metadata, column-info, data-access, site-metrics).
    export async function handleSocrataTool(params: Record<string, unknown>): Promise<unknown> {
      const { type } = params;
      
      switch (type) {
        case 'catalog':
          return handleCatalog(params as { query?: string; domain?: string; limit?: number; offset?: number });
        case 'categories':
          return handleCategories(params as { domain?: string });
        case 'tags':
          return handleTags(params as { domain?: string });
        case 'dataset-metadata':
          // Validate required parameters
          if (!params.datasetId) {
            throw new Error('datasetId is required for dataset-metadata operation');
          }
          return handleDatasetMetadata(params as { datasetId: string; domain?: string });
        case 'column-info':
          // Validate required parameters
          if (!params.datasetId) {
            throw new Error('datasetId is required for column-info operation');
          }
          return handleColumnInfo(params as { datasetId: string; domain?: string });
        case 'data-access':
          // Validate required parameters
          if (!params.datasetId) {
            throw new Error('datasetId is required for data-access operation');
          }
          // Map soqlQuery to query for consistency with the handler
          if (params.soqlQuery) {
            params.query = params.soqlQuery;
          }
          return handleDataAccess(params as { 
            datasetId: string; 
            domain?: string; 
            query?: string; 
            limit?: number; 
            offset?: number;
            select?: string;
            where?: string;
            order?: string;
            group?: string;
            having?: string;
            q?: string;
          });
        case 'site-metrics':
          return handleSiteMetrics(params as { domain?: string });
        default:
          throw new Error(`Unknown operation type: ${type}`);
      }
    }
  • Detailed input schema for the 'get_data' tool, defining all parameters including required 'type' enum for operation selection, optional domain, datasetId, various SoQL query parameters for data-access, pagination (limit/offset), and descriptions for each.
    inputSchema: {
      type: 'object',
      properties: {
        type: {
          type: 'string',
          enum: ['catalog', 'categories', 'tags', 'dataset-metadata', 'column-info', 'data-access', 'site-metrics'],
          description: 'The type of operation to perform:' +
            '\n- catalog: List datasets with optional search' +
            '\n- categories: List all dataset categories' + 
            '\n- tags: List all dataset tags' +
            '\n- dataset-metadata: Get detailed metadata for a specific dataset' +
            '\n- column-info: Get column details for a specific dataset' +
            '\n- data-access: Access records from a dataset (with query support)' +
            '\n- site-metrics: Get portal-wide statistics',
        },
        domain: {
          type: 'string',
          description: 'Optional domain (hostname only, without protocol). Used with all operation types.',
        },
        // Search and query parameters
        query: {
          type: 'string',
          description: 'Search or query string with different uses depending on operation type:' +
            '\n- For type=catalog: Search query to filter datasets' +
            '\n- For type=data-access: SoQL query string for complex data filtering',
        },
        // Dataset specific parameters
        datasetId: {
          type: 'string',
          description: 'Dataset identifier required for the following operations:' +
            '\n- For type=dataset-metadata: Get dataset details' +
            '\n- For type=column-info: Get column information' +
            '\n- For type=data-access: Specify which dataset to query (e.g., 6zsd-86xi)',
        },
        // Data access specific parameters
        soqlQuery: {
          type: 'string',
          description: 'For type=data-access only. Optional SoQL query string for filtering data.' +
            '\nThis is an alias for the query parameter and takes precedence if both are provided.',
        },
        // Additional SoQL parameters for data-access
        select: {
          type: 'string',
          description: 'For type=data-access only. Specifies which columns to return in the result set.',
        },
        where: {
          type: 'string',
          description: 'For type=data-access only. Filters the rows to be returned (e.g., "magnitude > 3.0").',
        },
        order: {
          type: 'string',
          description: 'For type=data-access only. Orders the results based on specified columns (e.g., "date DESC").',
        },
        group: {
          type: 'string',
          description: 'For type=data-access only. Groups results for aggregate functions.',
        },
        having: {
          type: 'string',
          description: 'For type=data-access only. Filters for grouped results, similar to where but for grouped data.',
        },
        // Full-text search parameter
        q: {
          type: 'string',
          description: 'For type=data-access only. Full text search parameter for free-text searching across the dataset.',
        },
        // Pagination parameters
        limit: {
          type: 'number',
          description: 'Maximum number of results to return:' +
            '\n- For type=catalog: Limits dataset results' +
            '\n- For type=data-access: Limits data records returned',
          default: 10,
        },
        offset: {
          type: 'number',
          description: 'Number of results to skip for pagination:' +
            '\n- For type=catalog: Skips dataset results' +
            '\n- For type=data-access: Skips data records for pagination',
          default: 0,
        },
      },
      required: ['type'],
      additionalProperties: false,
    },
  • src/index.ts:49-52 (registration)
    Dispatch/registration point in the MCP CallToolRequest handler where tool calls named 'get_data' are routed to the handleSocrataTool implementation.
    if (name === 'get_data') {
      // Handle the unified data retrieval tool
      result = await handleSocrataTool(args || {});
  • src/index.ts:117-120 (registration)
    Registration of the 'get_data' tool (via SOCRATA_TOOLS/enhancedTools) in the MCP ListToolsRequest handler, making it discoverable to clients.
    // Update the tools handler
    server.setRequestHandler(ListToolsRequestSchema, async () => ({
      tools: enhancedTools,
    }));
  • Key helper function invoked by 'get_data' handler for 'data-access' type, responsible for querying and retrieving actual data records from Socrata datasets using SoQL parameters.
    async function handleDataAccess(params: { 
      datasetId: string; 
      domain?: string;
      query?: string;
      limit?: number;
      offset?: number;
      select?: string;
      where?: string;
      order?: string;
      group?: string;
      having?: string;
      q?: string;
    }): Promise<Record<string, unknown>[]> {
      const { 
        datasetId, 
        domain = getDefaultDomain(),
        query,
        limit = 10,
        offset = 0,
        select,
        where,
        order,
        group,
        having,
        q
      } = params;
      
      const apiParams: Record<string, unknown> = {
        $limit: limit,
        $offset: offset,
      };
      
      // Handle comprehensive query parameter if provided
      if (query) {
        apiParams.$query = query;
      } else {
        // Otherwise handle individual SoQL parameters
        if (select) apiParams.$select = select;
        if (where) apiParams.$where = where;
        if (order) apiParams.$order = order;
        if (group) apiParams.$group = group;
        if (having) apiParams.$having = having;
        if (q) apiParams.$q = q;
      }
      
      const baseUrl = `https://${domain}`;
      const response = await fetchFromSocrataApi<Record<string, unknown>[]>(
        `/resource/${datasetId}.json`, 
        apiParams,
        baseUrl
      );
      
      return response;
    }
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'access data and metadata' but doesn't specify whether this is a read-only operation, what authentication might be required, rate limits, pagination behavior (beyond what's in the schema), or what format the data returns in. For a tool with 13 parameters and no output schema, this is a significant gap in behavioral context.

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

Conciseness3/5

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

The description is a single sentence that's appropriately concise but fails to be front-loaded with useful information. It wastes space on generic phrasing ('learn more about the city and its underlying information') rather than providing actionable guidance. While brief, it doesn't efficiently communicate the tool's purpose.

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

Completeness2/5

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

Given the tool's complexity (13 parameters, 7 operation types, no output schema, no annotations), the description is completely inadequate. It doesn't explain the different operation types, what 'data-access' actually returns, how to interpret results, or any portal-specific constraints. The description fails to provide the necessary context for effective tool use.

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%, so the schema already documents all 13 parameters thoroughly with clear descriptions of when each applies. The description adds no parameter information beyond what's in the schema. According to the scoring rules, when schema coverage is high (>80%), the baseline is 3 even with no param info in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Access data and metadata to learn more about the city and its underlying information' is vague and tautological. It restates the tool name 'get_data' without specifying what kind of data, from what source, or how it differs from other potential data access tools. There are no sibling tools mentioned, but the description fails to provide a clear verb+resource combination.

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 provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, constraints, or typical use cases. While there are no sibling tools listed, the description should still explain the tool's role within the broader Chicago Data Portal context, which it doesn't do.

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

Install Server

Other Tools

Related Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srobbin/opengov-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server