Elephant MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| LOG_LEVEL | No | Pino log level (error, warn, info, debug). | info |
| AWS_REGION | No | AWS region for Bedrock API calls. | us-east-1 |
| OPENAI_API_KEY | No | OpenAI API key for embeddings. When set, OpenAI is used; otherwise falls back to AWS Bedrock. | |
| ORACLE_GEO_INDEX_CID | No | Fixed CID of the derived geo/value index; used when ORACLE_GEO_INDEX_IPNS is unset. | |
| ORACLE_GEO_INDEX_IPNS | No | IPNS name of the derived geo/value index (e.g. oracle-geo-index-lee); resolved to its current CID at runtime. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| listClassesByDataGroupB | List classes for an Elephant data group with names and descriptions |
| listPropertiesByClassNameA | Lists JSON Schema property names for an Elephant class (excludes source_http_request) |
| getPropertySchemaB | Returns the full JSON Schema object for a class property |
| getVerifiedScriptExamplesC | Get most relevant working examples of the code, that maps data to the Elephant schema |
| listPublishedCountiesA | Returns every county in Oracle's canonical published-county catalog, including stable county keys, state codes, public query/coverage/permit URLs, nullable placesTableUrl, update timestamps, and a catalog revision. Use this tool to discover newly published counties and places availability instead of maintaining a hard-coded list. |
| listOraclePropertiesA | Paginated discovery of properties for a county. Returns slim entries (propertyId, parcelIdentifier, cid, county, fileSizeBytes) plus summary fields (address, marketValue, ownerName) when served from the query table. Use getOracleProperty to fetch full consolidated data for a specific entry. |
| getOraclePropertyA | Fetch the full consolidated property JSON (appraisal, permits, Sunbiz, BBB) from IPFS. Provide exactly one of parcelIdentifier, propertyId, or cid. |
| getOracleDatasetInfoA | Returns dataset-level metadata for a county: county, propertyCount (the catalog-bound appraisal row count when canonical coverage is available, otherwise a live query-table count), state, and provenance/CID fields on the legacy path. When per-source coverage is configured, also returns datasets[] with, per source (appraisal, permits, sunbiz, bbb), ingestedCount, expectedCount, completionPercent, and first/last loaded timestamps — so callers can qualify partial answers by coverage. For a coverage-only county (no property dataset served) propertyCount is null and propertyDatasetAvailable is false, so callers can distinguish a missing property table from a county with zero properties. |
| getPropertyPermitsA | Fetch permit records for a property by parcel ID. Returns cached permits immediately if available. If not cached, enqueues a harvest job (reuses the permit-harvest Lambda) and returns a status indicating the harvest is in progress — poll again after ~90 seconds. Permits are cached to IPFS after harvest completes. |
| findPropertiesInAreaA | Returns the set of properties whose centroid (latitude/longitude) falls inside a user-supplied bounding box or polygon. Provide exactly one of bbox or polygon. Reads the per-county property query table (falls back to the derived geo index); no NOAA/FEMA geometry is used. |
| sumPropertyValueInAreaA | Returns the exact sum of avm_value over the properties whose centroid falls inside a user-supplied bounding box or polygon, plus the in-area count. Null valuations are treated as 0. Provide exactly one of bbox or polygon. Reads the per-county property query table (falls back to the derived geo index). |
| getDatasetQueryCapabilitiesA | Describe bounded aggregate query capabilities for a county's property and permit datasets. Returns only allowlisted non-PII fields, types, operators, measures, null semantics, hard budgets, and query-table identity. It returns no source rows and accepts no SQL or data URL. |
| executeDatasetQueryPlanA | Execute one typed, bounded aggregate plan over a county's property or permit query table. The server independently allowlists fields, operators, grouping, measures, row/group/time budgets, compiles identifiers itself, and binds every value. Callers cannot provide SQL, URLs, joins, projections, expressions, raw-row queries, or mutations. Returns exact numerator, measured denominator, support, null completeness, median where relevant, canonical hashes, and query-table provenance. |
| queryPropertiesA | Run a read-only SQL SELECT against a county's flat property query table (view name 'properties', one row per property) backed by embedded DuckDB. Use getPropertyQuerySchema first to see available columns. SAFETY: a single SELECT statement only (a leading WITH/CTE is allowed); multiple statements and any mutating or file/extension keyword (INSERT/UPDATE/DELETE/COPY/ATTACH/INSTALL/LOAD/PRAGMA/CALL/SET …) are rejected; results are always capped at 1000 rows. |
| getPropertyQuerySchemaA | Returns the column list, DuckDB types, and a one-line description of each column of the 'properties' query table for a county, so queryProperties can be written without guessing. Notes that some coverage-dependent fields may be NULL. |
| queryPlacesA | Run a structured read-only query over a county's catalog-authorized Overture places parquet. Supports exact/contains category filters, '/'-hierarchy roll-ups, name/locality/postcode/status/confidence filters, hosted-service include/exclude/only, deterministic row pages with totalCount, count-only mode, and grouped taxonomy_primary aggregates. Call getPlaceQuerySchema first. Callers cannot provide SQL or data URLs; results are capped at 1000. |
| analyzePlaceColocationA | Return bounded diagnostic occupied-grid-cell evidence for one exact unordered taxonomy_primary pair in one published county. Spatial evidence is deterministic and uses a fixed-global-origin equirectangular grid plus 199 geography-and-density-conditioned permutations. Semantic evidence uses raw cosine distance over canonical category/hierarchy gloss embeddings, but this single-pair tool does not fabricate the full eligible-universe calibrated percentile. discoverPlaceColocationCandidates is the publishable Class H source unless separate auditable percentile evidence exists. Embedding failure preserves spatial evidence with semanticDistance.value=null. This tool never makes a publish decision. |
| discoverPlaceColocationCandidatesA | Discover a bounded county-wide family of Overture taxonomy_primary co-location candidates using a fixed 800m non-hosted occupied-cell universe and release-derived stratified discovery/validation split. Every eligible category is embedded; all eligible unordered pairs define an outcome-independent semantic reference distribution. Spatial pairs require raw cosine distance >=0.35 and inclusive empirical percentile >=0.80 before the top-32 analytic rank cap, then receive exact stratified hypergeometric validation and Holm adjustment. The county only response includes bounded evidence and canonical corpus/distribution/spatial-ledger digests. Percentile means relative semantic distance, not statistical improbability or a publish decision. |
| getPlaceQuerySchemaA | Returns the real published places parquet columns, field descriptions, structured queryPlaces contract, safety limits, Overture release/provenance and licence-gate metadata, and honest null completion semantics for a county. |
| queryPermitsA | Run a read-only SQL SELECT against a county's flat permit query table (view name 'permits', one row per building permit) backed by embedded DuckDB. Use getPermitQuerySchema first to see available columns and getPermitCoverage to qualify aggregate answers by source. SAFETY: a single SELECT statement only (a leading WITH/CTE is allowed); multiple statements and any mutating or file/extension keyword (INSERT/UPDATE/DELETE/COPY/ATTACH/INSTALL/LOAD/PRAGMA/CALL/SET …) are rejected; results are always capped at 1000 rows. |
| getPermitQuerySchemaA | Returns the column list, DuckDB types, and a one-line description of each column of the 'permits' query table for a county, so queryPermits can be written without guessing. Notes that date/value fields are frequently NULL depending on the permit source. |
| getPermitCoverageA | Returns per-source-system permit coverage for a county from the 'permits' query table: each source_system with its permit_count and completion_date range (earliest/latest), plus the overall total. The donphan agent uses this to QUALIFY aggregate permit answers (permit data lags appraisals and some sources may have NULL dates). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools have distinct purposes, but several names collide across subdomains: getPropertySchema (Elephant schema) vs getPropertyQuerySchema (county query table), and listPropertiesByClassName vs listOracleProperties. The detailed descriptions help, but an agent could easily misroute these calls.
The server mostly follows a predictable snake_case verb-noun pattern, with consistent query/schema pairs like queryProperties/getPropertyQuerySchema and queryPermits/getPermitQuerySchema. A few deviations such as getVerifiedScriptExamples and the overloaded getProperty* prefix slightly weaken the pattern, but naming is still largely predictable.
With 22 tools, the server sits in the heavy range and spans several related subdomains: schema metadata, property data, permits, places, and colocation analysis. Each tool has a real purpose, but the surface could reasonably be pruned or split without losing capability.
The tool set covers discovery, schema introspection, data retrieval, query execution, coverage qualification, and advanced analytics across the main entities. Minor gaps exist, such as no direct address/owner search beyond SQL and no place-detail-by-ID operation, but these are workable through existing tools.