This server exposes MCP tools for discovering Elephant lexicon/property schemas, querying Oracle open-data property and permit datasets, and analyzing Overture places.
Discover Elephant data groups, classes, property schemas, and verified script examples.
List Oracle's canonical published-county catalog and available places coverage.
Paginate through open-data properties and fetch full consolidated property JSON by parcel ID, property ID, or CID.
Retrieve dataset-level info and per-source coverage for appraisal, permits, Sunbiz, and BBB data.
Fetch property permits on demand, with caching and async harvest status.
Find properties inside a bounding box or polygon and sum property values in an area.
Inspect bounded aggregate query capabilities and execute typed, allowlisted dataset query plans (no raw SQL, no PII fields).
Run safely restricted read-only SQL over county properties and permits query tables and inspect their schemas.
Query published Overture places with filters, sorting, pagination, counts, and category group-by, plus get place query schema.
Analyze or discover Overture place co-location candidates with spatial and semantic evidence.
Provides an alternative embedding provider via AWS Bedrock for semantic code search when OpenAI is not configured.
Enables arbitrary SQL queries on property data through the queryProperties tool using embedded DuckDB.
Serves as the data storage layer, with property data published on IPFS and accessed via IPNS for geo tools and query-table.
Provides text embeddings for semantic code search in the getVerifiedScriptExamples tool.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Elephant MCP Server List classes for the 'County' data group. use elephant mcp"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Elephant MCP exposes lexicon tools and CID-verified Atlas county data through the Model Context Protocol. Atlas data is synchronized into local SQLite or hosted Postgres before tools query it; request handlers never query remote Parquet files.
Related MCP server: Baby-SkyNet
Node.js 22.18 or newer
Network access to the configured Atlas gateways
Postgres/Neon only for hosted deployments
npm install
npm run build
npm startThe stdio server stores Atlas data separately from verified-script embeddings under the Elephant MCP application-data directory. It begins one Atlas sync on startup. Atlas-backed tool calls wait for the accepted SQL snapshot.
MCP client configuration:
{
"mcpServers": {
"elephant": {
"command": "npx",
"args": ["-y", "@elephant-xyz/mcp@2"]
}
}
}Build first, then invoke the packaged CLI subcommand:
npm run build
npm run syncThe command:
Resolves the Atlas IPNS index through the configured gateways.
Computes the index CID from its bytes.
Verifies CountyIndex, CountyTables, and UnixFS Parquet CIDs.
Reads changed Parquet parts through DuckDB and loads them into SQL in batches.
Applies replacements and withdrawals atomically.
Prints the synchronized index CID and per-group counts.
An unchanged index performs no database writes.
The database holds one table per CountyTables table, named exactly as
published: one per lexicon class (property, address, company, ...), one
per relationship type (property_has_address, ...), and properties for the
per-property data-group roots. Columns come from the Parquet parts
(DESCRIBE read_parquet with union_by_name; new columns are added with
ALTER TABLE ... ADD COLUMN) plus state, county, and data_group.
Primary keys:
Table | Key |
lexicon class |
|
relationship |
|
|
|
export-tables writes each entity and relationship once per archive, with
property_cid set to the first property that referenced it. getAtlasProperty
therefore seeds with the property's own rows and follows relationship rows
from_cid to to_cid inside the scope (to a fixpoint or depth 8) to gather
people, companies, and addresses shared with earlier properties. Loading a group deletes its
state/county/data_group scope and reinserts it with ON CONFLICT DO UPDATE;
withdrawing a group is the delete alone. Both happen in one transaction.
Control tables: atlas_state (one row per loaded county/data group with its
archive, tables, and schema CIDs) and atlas_sync_state (the accepted index
CID). The atlas_ prefix is reserved; every other table in the database is
discovered from the catalog as Atlas content.
Set DATABASE_URL to a direct postgres:// or postgresql:// URL and run
mcp sync as a separate job. The HTTP deployment should use a read-only
database credential. HTTP requests never resolve IPNS, download parts, or run
DuckDB ETL.
Start the Node HTTP transport with:
npm run build
npm run start:httpThe MCP endpoint is POST /mcp; GET /health is public. Set
MCP_HTTP_AUTH_TOKEN to protect MCP routes.
Atlas SQL:
listAtlasCounties
listAtlasProperties
getAtlasProperty
getAtlasDatasetInfo
getAtlasSchema
queryAtlas
Lexicon and verified scripts:
listClassesByDataGroup
listPropertiesByClassName
getPropertySchema
getVerifiedScriptExamples
Atlas data tools require explicit state, county, and dataGroup scope
(county keys repeat across states). queryAtlas
accepts one read-only SELECT that names the synchronized tables directly
(property, address, property_has_address, properties, ...); each one is
shadowed by a CTE filtered to the requested state, county, and data group, and any
identifier that is not one of those tables, their columns, an alias, a function,
or a SQL keyword is rejected, so atlas_state, catalogs, and schema-qualified
names fail closed. Responses include the Atlas index, archive, tables, and
schema CIDs.
In the lexicon, coordinates live on geometry, parcel numbers on parcel and
property, and values on tax; reach them by JOIN through the relationship
tables. Properties in a bounding box with their market value:
SELECT p.parcel_identifier, g.latitude, g.longitude,
t.property_market_value_amount
FROM property p
JOIN property_has_address pa ON pa.from_cid = p.cid
JOIN address_has_geometry ag ON ag.from_cid = pa.to_cid
JOIN geometry g ON g.cid = ag.to_cid
LEFT JOIN property_has_tax pt ON pt.from_cid = p.cid
LEFT JOIN tax t ON t.cid = pt.to_cid
WHERE g.latitude BETWEEN 30.2 AND 30.4
AND g.longitude BETWEEN -81.8 AND -81.5Replace the SELECT list with count(*) and sum(t.property_market_value_amount)
to aggregate over the area.
Variable | Purpose | Default |
| Canonical Atlas IPNS name |
|
| Comma-separated gateway origins in retry order | Filebase, IPFS.io, dweb.link, w3s.link |
| Atlas SQLite or Postgres target | Separate SQLite file under the application-data directory |
| Bearer token for HTTP MCP routes | Unset |
|
|
|
| OpenAI embeddings for verified scripts | Optional |
| Vercel AI Gateway embeddings | Optional |
AWS credential chain | Bedrock embeddings | Optional |
DATABASE_URL accepts file:, postgres://, and postgresql://. Database
credentials are never logged.
npm run build
npm run test:ci
npm run lint
npm run format:checkAtlas tests cover shape validation, CID verification, SQLite synchronization, idempotence, column evolution, shared content, and withdrawal. The live Atlas and hosted Neon tests are environment-gated.
Return the row count of every table in one state/county/data group and its publication CIDs.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. 'FL'. | |
| county | Yes | Atlas county key, e.g. 'lee'. | |
| dataGroup | Yes | Atlas data-group key, e.g. 'county'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries behavioral weight. It clearly indicates a read-style operation returning row counts and CIDs, and 'every table' conveys scope. However, it does not disclose edge-case behavior, authorization needs, or output format details.
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?
A single, compact sentence states the action, the scope, and the two key outputs. There is no filler, and the most important information is front-loaded.
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 metadata-lookup tool with three fully documented parameters and no output schema, the description is largely sufficient: it names the inputs and the return contents. Minor ambiguity remains around the exact shape of the returned CIDs/row-count data, but overall an agent can call this tool confidently.
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 the schema already documents state, county, and dataGroup. The description adds only the aggregate notion that these parameters identify one dataset/group, without materially enriching individual 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 has a specific verb ('Return') and resource: row counts and publication CIDs for all tables in a state/county/data group. It is distinct from siblings like listAtlasCounties or getAtlasSchema, though it does not explicitly name how it differs.
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?
No guidance is given about when to use this tool versus siblings such as queryAtlas, getAtlasSchema, or listPropertiesByClassName. The description implies the input context but provides no exclusions or alternative selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Assemble one property: its roots, class rows, relationship rows, and the entities they reach.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. 'FL'. | |
| county | Yes | Atlas county key, e.g. 'lee'. | |
| dataGroup | Yes | Atlas data-group key, e.g. 'county'. | |
| propertyCid | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the assembled data ('roots, class rows, relationship rows, and the entities they reach') but does not state whether this is a read-only operation, what the response format is, whether it requires authentication, or any potential side effects. For a data retrieval tool, the lack of annotation means the description should at least hint at the operation type and output, but it doesn't.
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 very concise, a single sentence of 19 words, with no filler. It front-loads the primary action ('Assemble one property') and then lists the components. Every word earns its place, and it is well-structured for quick comprehension.
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's complexity (assembling multiple related datasets) and the absence of an output schema and annotations, the description is too brief. It explains what it returns but not how to interpret the results, what the 'entities they reach' means in practice, or whether the operation is safe. With four required parameters and a rich return, a more thorough description is warranted to ensure correct usage.
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 75%, with three parameters documented (state, county, dataGroup) but propertyCid lacks a description. The description does not add any parameter-specific meaning beyond what the schema provides. Given the moderate coverage gap, the description could compensate by explaining how propertyCid relates to the property being assembled, but it does not. The description is too generic to help an agent understand the nuances of the parameters.
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 ('Assemble') and identifies the resource ('one property') and the assembled components ('roots, class rows, relationship rows, and the entities they reach'). This makes the purpose clear, though it does not explicitly differentiate from sibling tools like getPropertySchema, which returns the property's schema rather than its data. Still, the description conveys what the tool does without being a tautology.
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 that this tool is for retrieving a full property graph, but it does not provide explicit guidance on when to use it versus alternatives like queryAtlas or listPropertiesByClassName. There are no exclusions or alternative tool mentions. The context is clear enough for a knowledgeable user, but it leaves the decision to the agent without explicit routing instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tables of one state/county/data group, or the columns of one table, for queryAtlas.
| Name | Required | Description | Default |
|---|---|---|---|
| state | Yes | Two-letter state code, e.g. 'FL'. | |
| table | No | ||
| county | Yes | Atlas county key, e.g. 'lee'. | |
| dataGroup | Yes | Atlas data-group key, e.g. 'county'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It indicates a read-only listing action, but it does not describe the return shape, whether tables and columns are returned in a single structure, error behavior, or any access requirements. This is a significant gap for a tool with no annotation safety net.
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 entire description is a single front-loaded sentence with no filler. It states the main behavior and the optional mode in a compact, scannable way.
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 schema-listing tool, the description covers the core modes, but it does not explain what the returned schema data looks like and there is no output schema to compensate. An agent could invoke it correctly but might be unsure how to interpret the response.
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 schema already documents state, county, and dataGroup, and the description adds the key semantic that the optional 'table' parameter switches the output from table listing to column listing. This clarifies the interaction between parameters beyond what the schema alone states.
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 ('List') and clearly names the two resources it exposes: tables for a state/county/data-group scope, or columns for a single table. This is enough for an agent to understand what the tool does and to distinguish it from data-querying siblings like queryAtlas.
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 phrase 'for queryAtlas' implies that this tool is meant to be used as a schema-discovery step before querying, but the description never explicitly states when to use this tool over siblings such as getAtlasDatasetInfo or listPropertiesByClassName. No exclusions or alternative-selection guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return the lexicon schema for one class property.
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes | ||
| propertyName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden. 'Return' signals a non-mutating lookup, which is a useful behavioral trait, but the description does not mention output shape, error behavior, permissions, or side-effect guarantees, so transparency is only minimal.
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?
One short sentence with no filler. The verb and resource are front-loaded, and every word contributes to the core meaning.
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 no output schema, no annotations, and no usage guidance, this description is thin. An agent can infer the basic call, but it has no sense of the returned schema's structure or how this tool differs from nearby siblings.
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 0% and the description does not explain className or propertyName beyond their implied roles in 'one class property.' The parameter names are self-evident, but no accepted values, formatting, or relationship between the two parameters is provided.
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 and resource: 'Return the lexicon schema for one class property.' It clearly identifies the target object, though it doesn't explicitly differentiate from siblings like getAtlasProperty or getAtlasSchema.
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?
There is no guidance about when to choose this tool over the sibling tools, no stated exclusions, and no mention of prerequisites. The only hint is the phrase 'one class property,' which implies a targeted lookup but falls short of explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search verified Elephant transform scripts semantically.
| Name | Required | Description | Default |
|---|---|---|---|
| topK | No | ||
| query | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the burden. 'Semantically' and 'verified' do convey meaningful behavior about how matching and the corpus are scoped. However, it does not disclose what the response looks like or any side effects, though as a read-oriented search tool the core behavior is reasonably transparent.
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?
One front-loaded sentence contains no filler and covers the tool's purpose and mode. Every word adds information, and there is no duplicated 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?
For a simple low-complexity search tool, the description plus schema is minimally adequate: required and optional parameters are present, and the semantic-search behavior is stated. But without annotations or an output schema, an agent is left to infer the return structure and the effect of topK from naming conventions.
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 0%, so the description must compensate for both parameters. It clarifies that 'query' is a semantic search phrase but never explains 'topK' or how the two parameters interact. 'topK' can be inferred from its name and schema bounds, but the description itself does not add this semantic value.
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 ('Search') and resource ('verified Elephant transform scripts') and adds the mode 'semantically,' which crisply distinguishes this from the Atlas-metadata sibling tools. A single sentence tells an agent exactly what the tool operates on and how.
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 establishes clear context: semantic search over verified Elephant transform scripts, so an agent can infer when to call it. It does not name explicit exclusions or alternatives, but no sibling tool overlaps with script search, so the absence is not a practical gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the synchronized counties, their data groups, and publication CIDs.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It conveys this is a read/retrieval operation and specifies the returned entities, but it does not disclose whether the list reflects a synced snapshot, requires authorization, or has pagination or ordering behavior.
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 word contributes: the operation, the resource, and the three output components.
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 no-parameter list operation with no output schema, this is nearly complete: it names all output components and makes the tool's purpose clear. It would only benefit from clarifying the exact return shape or the meaning of 'synchronized,' but the low complexity keeps the gap small.
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?
There are no parameters, so the input schema has nothing to document; the baseline is 4. The description's mention of specific output components adds useful context even though no parameter semantics are needed.
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 the specific verb 'List' and clearly identifies the resource ('synchronized counties') and the return contents ('data groups, publication CIDs'). This distinguishes it from sibling tools like listAtlasProperties, which target properties rather than counties.
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?
Usage is implied: call this tool when you need a county-level listing with its data groups and publication CIDs. It does not explicitly state when-not-to-use it or mention alternative sibling tools, but the no-parameter, list-only nature reduces the risk of mis-selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the property CIDs and data-group roots of one state/county/data group.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| state | Yes | Two-letter state code, e.g. 'FL'. | |
| county | Yes | Atlas county key, e.g. 'lee'. | |
| offset | No | ||
| dataGroup | Yes | Atlas data-group key, e.g. 'county'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It conveys a read-only listing intent and names the result items, but it does not mention pagination (despite limit/offset parameters), result ordering, possible large result sets, or return format. The 'list' verb implies safety, but explicit disclosure is lacking.
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 sentence with no filler, front-loading the action verb 'List' and then stating the resource and scope. It is as concise as possible while conveying the core operation, even if 'data-group roots' is not fully self-explanatory.
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 list tool with no output schema and no annotations, this description gives the essential gist and names the expected result items. However, it omits pagination behavior and a clear return structure, which an agent would need to handle large datasets correctly. It is adequate but not complete.
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 60%; state, county, and dataGroup are described with examples, while limit and offset have no descriptions. The description reinforces that the three required parameters define the selection scope but adds no detail about limit/offset behavior. The parameter names are self-explanatory, so a mid-range score 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 action ('List') and a specific resource ('property CIDs and data-group roots'), with an explicit scope ('of one state/county/data group'). It helps differentiate from siblings like getAtlasProperty and listPropertiesByClassName, though the phrase 'data-group roots' is somewhat jargony and could be clearer.
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?
No guidance is given on when to use this tool over alternatives such as listPropertiesByClassName or listClassesByDataGroup. The only hint is the scope phrase 'one state/county/data group', which implies a single geo/data scope but does not explicitly exclude other cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List lexicon classes in one Elephant data group.
| Name | Required | Description | Default |
|---|---|---|---|
| groupName | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The word 'List' implies a read-only enumeration and the phrase 'one ... data group' communicates its scoping behavior. However, there are no annotations, so the description must fully disclose behavior itself; it does not mention pagination, error conditions, or exactness of groupName matching.
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 the verb and scope front-loaded. There is no filler or repetition of the tool name.
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 one-parameter list operation this is nearly adequate, but with no output schema and no annotations, an agent is left uncertain about what a returned 'lexicon class' looks like and what counts as a valid Elephant data group. Missing details include whether groupName must be an exact name and whether the result is a list of class names or richer class metadata.
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 description connects the only parameter to the concept of a data group ('one Elephant data group'), which adds some meaning beyond the bare schema property. With 0% schema description coverage, this is helpful, but it doesn't define valid group name format, allowable values, or expected examples.
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 specific verb ('List'), a specific resource ('lexicon classes'), and a clear scope ('one Elephant data group'). This is distinct from sibling tools, which target Atlas properties, datasets, schemas, and counties rather than lexicon classes.
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?
There is no guidance on when to use this tool instead of listPropertiesByClassName, listAtlasProperties, or other siblings. No conditions, exclusions, or alternative-selection cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List non-deprecated lexicon properties for one class.
| Name | Required | Description | Default |
|---|---|---|---|
| className | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does add useful selection details ('non-deprecated', 'lexicon', 'one class'), but it omits return shape, pagination, ordering, or behavior for an unknown class name.
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 or repetition. It is efficiently structured, though arguably too terse to provide richer guidance.
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 one-parameter list tool, the description states the required input and the filtering rule, which is nearly enough. Missing usage contrast with siblings and return-value caveats keep it from being fully complete.
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 schema's only parameter, 'className', has no description, and the tool description partially compensates by saying the operation targets one class. However, it does not clarify the expected class-name format or whether a fully qualified name is required.
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 specific verb ('List') and resource ('non-deprecated lexicon properties') and scopes the operation to 'one class', so an agent can tell what the tool does. It is clear, though it does not explicitly contrast itself with sibling tools such as listAtlasProperties.
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?
No guidance is given about when to choose this tool over listAtlasProperties, getPropertySchema, or getAtlasProperty. The intended usage context must be inferred from the tool name and the phrase 'for one class.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run one read-only SELECT over the synchronized tables of one state/county/data group. Table names are those from getAtlasSchema (property, address, properties, ...).
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | ||
| limit | No | ||
| state | Yes | Two-letter state code, e.g. 'FL'. | |
| county | Yes | Atlas county key, e.g. 'lee'. | |
| dataGroup | Yes | Atlas data-group key, e.g. 'county'. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the key behavioral trait of being read-only and scoped to one state/county/data group, which is valuable. However, it does not mention pagination behavior, result formatting, error handling, or any rate limits, leaving significant gaps for a SQL query tool.
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, front-loaded with the core action, and includes only essential detail. The reference to getAtlasSchema is directly useful and not extraneous. No wasted words.
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 SQL query tool with no output schema, the description is notably incomplete. It does not explain the shape of the response, how limit behaves, what happens on invalid SQL, or how results are ordered. The pointer to getAtlasSchema is helpful but does not cover the operational details an agent needs to confidently invoke the tool.
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 description adds meaning to the sql parameter by specifying it must be a SELECT query, and it connects to getAtlasSchema to define valid table names. This compensates for the schema lacking descriptions for sql and limit. State/county/dataGroup already have descriptions in the schema, so the description focuses where it adds value.
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 ('Run'), a resource ('read-only SELECT over the synchronized tables'), and a clear scope ('one state/county/data group'). It is clearly distinct from sibling metadata tools like getAtlasSchema or listPropertiesByClassName, which are for schema discovery, not data querying.
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 to run a SELECT query against synced tables. It also provides a useful pointer that table names come from getAtlasSchema. However, it does not explicitly state when not to use it or name alternative tools for other query patterns, so 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.13.0analyzePlaceColocationdiscoverPlaceColocationCandidatesexecuteDatasetQueryPlanfindPropertiesInAreagetAtlasDatasetInfogetAtlasPropertygetAtlasSchemagetDatasetQueryCapabilitiesgetOracleDatasetInfogetOraclePropertygetPermitCoveragegetPermitQuerySchemagetPlaceQuerySchemagetPropertyPermitsgetPropertyQuerySchemagetPropertySchema2 fields changedInput schema / properties / className / descriptionRemoved value: -"Class name, case-insensitive"Input schema / properties / propertyName / descriptionRemoved value: -"Property name, case-insensitive"getVerifiedScriptExamples2 fields changedInput schema / properties / query / descriptionRemoved value: -"Description of the example meaning. Wll be used to search for similar examples."Input schema / properties / topK / descriptionRemoved value: -"Number of results (default 5)"listAtlasCountieslistAtlasPropertieslistClassesByDataGroup1 field changedInput schema / properties / groupName / descriptionRemoved value: -"The data group name, case-insensitive"listOraclePropertieslistPropertiesByClassName1 field changedInput schema / properties / className / descriptionRemoved value: -"The class name, case-insensitive"listPublishedCountiesqueryAtlasqueryPermitsqueryPlacesqueryPropertiessumPropertyValueInAreav1.12.1analyzePlaceColocationdiscoverPlaceColocationCandidatesexecuteDatasetQueryPlanfindPropertiesInAreagetDatasetQueryCapabilitiesgetOracleDatasetInfogetOraclePropertygetPermitCoveragegetPermitQuerySchemagetPlaceQuerySchemagetPropertyPermitsgetPropertyQuerySchemagetPropertySchemagetVerifiedScriptExampleslistClassesByDataGrouplistOraclePropertieslistPropertiesByClassNamelistPublishedCountiesqueryPermitsqueryPlacesqueryPropertiessumPropertyValueInAreaScored across 10 tools
Each tool serves a distinct purpose: listing vs. getting specific Atlas properties, dataset info, schema access, lexicon queries, and script search. There is no overlap or ambiguity between the tools.
All tool names follow a consistent camelCase verb_noun pattern (list, get, query) with clear resource nouns, making it easy to predict behavior from names.
The 10 tools cover the read-only data access and lexicon schema domain without redundancy. The count is well within the ideal range for a focused server.
The surface covers the core workflows: listing datasets/counties, inspecting schemas, running queries, and retrieving lexicon details. The read-only nature is clearly communicated, and no critical operations are missing for the apparent purpose.
Connect your team's living knowledge base — docs, data, issues, CRM — to Claude and ChatGPT.
Connect Claude, Cursor, or ChatGPT to your business data. Ask questions, get answers.
Connect Claude to your Platform7n workspaces — chat, links, and tasks. One-click OAuth.
Build and supervise fleets of agents from Claude Code, Codex or Cursor. Connects over OAuth.
