SiteCheck Company Records

San Francisco police incident reports from the city open

gov_sf_open_data

Read-only

San Francisco police incident reports from the city open data portal (data.sf.gov, dataset wg3w-h783): date and time, category, subcategory, description, resolution and police district. Newest reports first; reports as filed, not verified outcomes. Related tools on this server, for a different need: gov_canada_open_data when you need Canadian federal open datasets from open.canada.ca: title; gov_dati_gov_it_italy_open_data when you need Italian open government datasets from dati.gov.it: title. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "gov_sf_open_data"
  }
}

Input Schema

Name	Required	Description	Default
`limit`	No	Reports to return, 1 to 20 (default 5)
`category`	No	Optional incident category, exact text, e.g. Lost Property

Output Schema

Name	Required	Description	Default
`source`	No
`reports`	No
`category`	No
`checkedAt`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint, openWorldHint), and the description adds real behavioral context beyond them: newest-first ordering, the caveat that reports are as filed and not verified outcomes, and the x402 payment model with failed calls free. That pricing detail is unusually useful for an agent deciding whether to call. It does not explain paging behavior or rate limits.

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 lead sentence is well front-loaded with dataset identity and field list, but the sibling-tool sentence is bloated, ending in dangling fragments like 'open.canada.ca: title;' and 'dati.gov.it: title.' that add no information. The pricing sentence is long but earns its place; the middle clause does not.

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?

With an output schema present, return-field explanation is unnecessary, and the description covers source, fields, ordering, data-quality caveat and cost. The main remaining gap is what happens beyond the 20-row cap, i.e. whether pagination or date scoping exists, which an agent would want before calling.

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 description coverage is 100% and both parameters are documented in-schema (limit 1-20 default 5, category exact text with an example), so the description is not required to carry this. The 'newest reports first' note adds ordering semantics the schema does not state. Baseline plus that ordering context justifies a 4.

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

Purpose4/5

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

Names a specific resource (San Francisco police incident reports) plus the source portal and dataset ID (wg3w-h783) and enumerates the fields returned, which lets an agent know exactly what data it gets. It also explicitly separates itself from two sibling open-data tools by country. It falls short of 5 only because there is no explicit verb (fetch/query) stating the operation.

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 'Related tools on this server, for a different need' clause effectively routes the agent away to gov_canada_open_data and gov_dati_gov_it_italy_open_data for non-SF datasets, which is clear context. It gives no guidance about when this tool is a poor fit within its own domain (e.g. no date filtering, only 20 rows max), so no explicit exclusions.

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

All SiteCheck Company Records tools Inspect

Try in Browser

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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?