Wherobots
Server Details
Generate and run high performance queries on open and private spatial data at-scale in the cloud
- Status
- Unhealthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.5/5 across 7 of 7 tools scored.
Each tool has a clear, distinct purpose: describing tables, executing queries, generating spatial queries, listing catalogs/databases/tables, and searching documentation. No overlap or ambiguity.
All tools follow a consistent snake_case naming pattern ending with '_tool', e.g., describe_table_tool, execute_query_tool. Very predictable.
7 tools cover essential operations for a spatial SQL database server: data discovery, schema inspection, query execution, query generation, and documentation search. Well-scoped for its purpose.
Covers the full read/exploration workflow. Missing DDL/DML tools (create/insert/update/delete) but those are likely out of scope for this server. Minor gap: no tool to list views or functions.
Available Tools
7 toolsdescribe_table_toolDescribe Wherobots Catalog TableARead-onlyInspect
Describe a specific table.
This tool retrieves the schema of a specified table, including column names and types. It is used to understand the structure of a table before querying or analysis.
Parameters
catalog : str The name of the catalog. database : str The name of the database. table : str The name of the table. ctx : Context FastMCP context (injected automatically)
Returns
TableDescriptionOutput A structured object containing the table schema information. - 'schema': The schema of the table, which may include column names, types, and other metadata. - 'comment': Table-level description/comment, if set via TBLPROPERTIES. - 'properties': User-set table properties (filtered to exclude internal Iceberg properties). - 'row_count': Number of rows in the table, from table statistics. - 'last_updated': Timestamp of the latest snapshot (ISO 8601). - 'partition_columns': Partition spec with resolved column names and transforms.
Example Usage for LLM:
When user asks for the schema of a specific table.
Example User Queries and corresponding Tool Calls:
User: "What is the schema of the 'users' table in the 'default' database of the 'wherobots' catalog?"
Tool Call: describe_table('wherobots', 'default', 'users')
User: "Describe the buildings table structure"
Tool Call: describe_table('wherobots_open_data', 'overture', 'buildings')
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | ||
| catalog | Yes | ||
| database | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| schema | Yes | Table schema fields |
| comment | No | Table-level description/comment |
| row_count | No | Number of rows in the table |
| properties | No | User-set table properties (e.g. update frequency, source, query hints) |
| last_updated | No | Timestamp of the latest snapshot (ISO 8601) |
| partition_columns | No | Partition spec with resolved column names and transforms. Add partition filters on these columns to improve query performance. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the tool retrieves schema without side effects, consistent with readOnlyHint. It details the output fields (schema, comment, properties, row_count, last_updated, partition_columns), providing transparency beyond annotations about what the tool returns.
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 well-structured with sections for purpose, parameters, returns, and examples. It is slightly longer than necessary but each part serves a purpose (especially the example mappings). Front-loaded with core purpose.
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?
The description covers all needed aspects: purpose, parameters, return value structure, and usage examples. Given the tool has only three simple string parameters and an output schema, the description is complete and leaves no ambiguity.
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?
Input schema has three string parameters with no descriptions (0% coverage). The description lists each parameter with a brief description and provides concrete example values in usage examples. This adds sufficient meaning for the agent to correctly populate 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 clearly states the tool retrieves the schema of a specified table, using the verb 'describe' and identifying the resource as a 'specific table'. It distinguishes from siblings like list_tables_tool and execute_query_tool by focusing on schema retrieval rather than listing or 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 says it is used to understand table structure before querying or analysis, and provides explicit example queries mapping to tool calls. It does not explicitly state when not to use or compare to alternatives like execute_query_tool, but the context and examples make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
execute_query_toolExecute SQL QueryARead-onlyInspect
Run the SQL query on a Wherobots catalog.
This tool allows users to execute SQL queries against the Wherobots catalog. It is typically used for data retrieval and analysis. Supports pagination for large result sets.
The query is freeform SQL written in the WherobotsDB Spatial SQL dialect
(Apache Sedona SQL, Spark SQL compatible). See the Wherobots SQL reference at
https://docs.wherobots.com/ for supported functions and syntax.
Behavior notes:
The output can be serialized to JSON.
Use limit and offset parameters for large result sets to avoid timeouts.
Queries have a maximum execution time (configurable via settings or x-query-timeout header).
The runtime ID can be set via the x-runtime-id header; any runtime string is accepted and when omitted the organization's default runtime is used.
The runtime region can be set via the x-runtime-region header; any region string (BYOC regions included) is accepted and when omitted the organization's default region is used.
The server sends periodic heartbeat messages during long-running queries to keep the connection alive.
If the client disconnects, the query will be cancelled to avoid wasting resources.
Parameters
query : str The SQL query to be executed. ctx : Context FastMCP context (injected automatically) limit : int | None Optional maximum number of rows to return (default: 1000, max: 10000) offset : int | None Optional number of rows to skip for pagination (default: 0)
Returns
QueryExecutionOutput A structured object containing the results of the query execution. - 'success': Whether the query executed successfully - 'row_count': Number of rows returned - 'data': Query results as a list of dictionaries - 'query': The executed SQL query - 'error': Whether an error occurred - 'error_type': Type of error (if any) - 'error_message': Error message (if any) - 'execution_status': Status of execution
Example Usage for LLM:
When user asks to run a specific SQL query.
Example User Queries and corresponding Tool Calls:
User: "Run the following SQL query: SELECT * FROM buildings WHERE state = 'California';"
Tool Call: execute_query('SELECT * FROM buildings WHERE state = 'California';')
User: "Execute this query with only the first 100 results"
Tool Call: execute_query('SELECT * FROM large_table;', limit=100)
User: "Get the next page of results"
Tool Call: execute_query('SELECT * FROM large_table;', limit=100, offset=100)
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| offset | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| data | Yes | Query result data |
| error | No | Whether an error occurred |
| query | Yes | The executed SQL query |
| success | No | Whether the query execution was successful |
| next_step | No | Recommended next action based on results or errors. |
| row_count | Yes | Number of rows returned |
| error_type | No | Type of error if any |
| error_message | No | Error message if any |
| execution_status | No | Execution status |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral notes: pagination, maximum execution time, runtime ID/region headers, heartbeat messages, and disconnection handling. This goes beyond annotations, though some edge cases (e.g., concurrency limits) are not mentioned, but overall it's solid.
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 well-structured with clear sections (Purpose, Behavior notes, Parameters, Returns, Example Usage) and is front-loaded with the main purpose. It contains some redundancy (e.g., example queries repeating tool call syntax), but overall each section earns its place. Minor trimming could improve conciseness.
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 (SQL execution), zero schema coverage, presence of output schema, and sibling tools, the description is highly complete. It covers input, behavior (timeout, headers, pagination), output structure, and provides concrete examples. No gaps are apparent for agent decision-making.
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 0%, meaning the description bears full responsibility. It explains 'query' as freeform SQL with a reference to the Wherobots SQL dialect, and details 'limit' and 'offset' for pagination with defaults and max values. The returns section fully describes the output structure, adding significant meaning beyond the schema.
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 clearly states the tool's purpose: 'Run the SQL query on a Wherobots catalog.' It specifies the verb (Run/Execute) and resource (SQL query on Wherobots catalog), distinguishing it from siblings like describe_table_tool and list_catalogs_tool. The examples further reinforce the specific use case of executing SQL queries for data retrieval and analysis.
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 provides clear context for usage: 'typically used for data retrieval and analysis' and includes examples of when to call the tool (e.g., user asking to run a specific SQL query). It also explains parameter usage (limit/offset for pagination). However, it does not explicitly state when not to use this tool or mention alternatives, which would boost clarity further.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_spatial_query_toolGenerate Spatial SQL QueryARead-onlyInspect
Generate a spatial query based on the provided content.
This tool allows user to translate their request into a spatial query. It searches the Wherobots documentation for relevant context and uses it to produce a Wherobots Spatial SQL query for the user's request.
Parameters
user_prompt : str The user's request or description of the spatial query they want to generate. ctx : Context FastMCP context (injected automatically)
Returns
QueryGenerationSummaryOutput A structured object containing the generated spatial query.
Example Usage for LLM:
When user asks to generate a spatial query based on their request.
When a user asks for information, statistics or analysis on data that is in tables within one or more of the catalogs they have access to in Wherobots.
Example User Queries and corresponding Tool Calls:
User: "Generate a SQL query to count buildings in California using Overture data."
Tool Call: generate_spatial_query("Generate a SQL query to count buildings in California using Overture data.")
User: "How can I find all parks within 5km of downtown Seattle?"
Tool Call: generate_spatial_query("How can I find all parks within 5km of downtown Seattle?")
| Name | Required | Description | Default |
|---|---|---|---|
| user_prompt | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | The generated spatial query. |
| next_step | No | Recommended next action in the workflow. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. Description adds the behavior of searching Wherobots documentation for context before generating the query, which provides useful context.
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?
Well-structured with sections (description, parameters, returns, example usage), but slightly verbose with repeated examples; front-loads key information.
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?
Single-parameter tool with output schema, sibling tools cover related operations, and example usage fills in context for how to call 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?
Even though schema description coverage is 0%, the description includes a clear docstring for the user_prompt parameter, adding meaning beyond the raw schema.
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 clearly states the tool generates a spatial SQL query based on user prompt, and contrasts with sibling tools like execute_query and describe_table.
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?
Provides explicit example usage scenarios and example user queries, but lacks explicit 'when not to use' or differentiation from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_catalogs_toolList Wherobots CatalogsARead-onlyInspect
List all catalogs available for users.
⚠️ LARGE RESULT WARNING: For large organizations this can return many thousands of catalogs in a single response, which may overflow the context window. If the result may be large, consider calling this tool from a subagent so the full list stays out of the main conversation's context.
This tool retrieves all available catalogs accessible with the provided API key. It is typically used as the first step in exploring the data hierarchy. This tool will fetch both managed catalogs, as well as external catalogs. (e.g., on Databricks)
Parameters
ctx : Context FastMCP context (injected automatically)
Returns
CatalogListOutput A structured object containing catalog information. - 'catalogs': List of catalog names. - 'count': Number of catalogs found.
Example Usage for LLM:
When user asks for available catalogs.
Example User Queries and corresponding Tool Calls:
User: "What catalogs are available?"
Tool Call: list_catalogs()
User: "Show me all the data sources"
Tool Call: list_catalogs()
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of catalogs. |
| catalogs | Yes | List of catalog names. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe, read-only operation. The description complements this by warning about large result sizes and specifying that both managed and external catalogs are returned, adding value beyond annotations.
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 well-structured with clear sections (warning, typical use, parameters, returns, examples). It is slightly verbose with example queries but remains focused and front-loaded. Could trim example section for conciseness.
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 zero parameters and the existence of an output schema, the description covers all necessary aspects: purpose, usage context, behavioral warning, and return structure. It is complete for an agent to understand when and how to 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?
With zero parameters and 100% schema coverage, the baseline is 3. The description adds meaning by listing return fields ('catalogs' and 'count') and stating that ctx is auto-injected, which is helpful for understanding the output beyond the schema.
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 clearly states 'List all catalogs available for users.' It is specific and distinct from sibling tools like list_databases_tool and list_tables_tool, which operate at different hierarchy levels.
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 explicitly mentions it is 'typically used as the first step in exploring the data hierarchy' and provides a warning about large results, guiding when to use a subagent. However, it does not explicitly state when not to use it compared to other tools like describe_table_tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_databases_toolList Wherobots Catalog DatabasesARead-onlyInspect
List all databases in a given catalog.
⚠️ LARGE RESULT WARNING: For large catalogs this can return many thousands of databases in a single response, which may overflow the context window. If the catalog may be large, consider calling this tool from a subagent so the full list stays out of the main conversation's context.
This tool retrieves all databases within a specified catalog.
Parameters
catalog : str The name of the catalog. ctx : Context FastMCP context (injected automatically)
Returns
DatabaseListOutput A structured object containing database information. - 'catalog': The catalog name. - 'databases': List of database names. - 'count': Number of databases found.
Example Usage for LLM:
When user asks for a specific catalog's databases.
Example User Queries and corresponding Tool Calls:
User: "List all databases in the 'wherobots' catalog."
Tool Call: list_databases('wherobots')
User: "What databases are in the foursquare catalog?"
Tool Call: list_databases('foursquare')
| Name | Required | Description | Default |
|---|---|---|---|
| catalog | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of databases. |
| catalog | Yes | Name of the catalog. |
| databases | Yes | List of database names. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint and openWorldHint. The description adds a large result warning and explains the return structure, providing behavioral context beyond the annotations.
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 well-structured with sections but somewhat verbose, repeating the purpose in multiple places. The warning is front-loaded, but could be more concise.
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?
With one parameter and an output schema, the description covers purpose, large result warning, parameter meaning, return values, and usage examples, making it 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?
Schema coverage is 0%, so description must compensate. It explains the 'catalog' parameter as the catalog name and documents the return structure, adding semantic meaning beyond the schema.
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 name and description clearly state the tool lists all databases in a given catalog. It distinguishes from sibling tools like list_catalogs_tool and list_tables_tool.
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 provides example user queries and corresponding tool calls, indicating when to use. It also includes a large result warning, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_tables_toolList Wherobots Catalog TablesARead-onlyInspect
List all tables in a given database.
⚠️ LARGE RESULT WARNING: For large catalogs this can return many thousands of tables in a single response, which may overflow the context window. If the database may be large, consider calling this tool from a subagent so the full list stays out of the main conversation's context.
This tool retrieves all tables within a specified database in a catalog. It is used to explore the final level of the data hierarchy before accessing table schemas.
Parameters
catalog : str The name of the catalog. database : str The name of the database. ctx : Context FastMCP context (injected automatically)
Returns
TableListOutput A structured object containing table information. - 'catalog': The catalog name. - 'database': The database name. - 'tables': List of table names. - 'count': Number of tables found.
Example Usage for LLM:
When user asks for a specific database's tables.
Example User Queries and corresponding Tool Calls:
User: "List all tables in the 'default' database of the 'wherobots' catalog."
Tool Call: list_tables('wherobots', 'default')
User: "What tables are in the overture database?"
Tool Call: list_tables('wherobots_open_data', 'overture')
| Name | Required | Description | Default |
|---|---|---|---|
| catalog | Yes | ||
| database | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| count | Yes | Total number of tables. |
| tables | Yes | List of table names. |
| catalog | Yes | Name of the catalog. |
| database | Yes | Name of the database. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint true and openWorldHint true, which the description does not contradict. The description adds behavioral context: it warns about large results potentially overflowing context, explains it returns a structured object with fields, and positions it as exploring the final level before schemas. This adds value beyond annotations.
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 well-structured with sections for parameters, returns, and example usage. It is front-loaded with the main purpose and a prominent warning. Every sentence adds value, and the length is appropriate for the tool's complexity.
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 simple tool with 2 parameters and an output schema, the description fully explains the return structure (catalog, database, tables list, count) and provides multiple examples. It covers usage context, large result handling, and positioning among siblings. It is complete for effective use.
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 input schema has 2 string parameters with 0% description coverage in schema properties. The description compensates by explaining each parameter's meaning and providing concrete example values (e.g., 'wherobots', 'default') in the usage examples. This adds practical semantics beyond the schema.
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 specific verb 'List' and resource 'tables' and clarifies it lists within a given database. It distinguishes from siblings by explicitly mentioning it's the final level of data hierarchy before accessing table schemas, and sibling tools include list_catalogs and list_databases, so this is clearly for tables.
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 provides example user queries and tool calls, and includes a warning for large databases suggesting use of subagent. However, it does not explicitly state when not to use this tool or mention alternatives, though no direct alternative exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_documentation_toolSearch Wherobots DocumentationARead-onlyInspect
Search the Wherobots documentation.
This tool searches the official Wherobots documentation to find relevant information about spatial functions, data formats, best practices, and more. It's useful when users need help understanding Wherobots features or syntax.
Parameters
query : str The search query string ctx : Context FastMCP context (injected automatically) page_size : int | None Optional number of results to return (default: 10)
Returns
DocumentationSearchOutput A structured object containing documentation search results. - 'results': List of DocumentResult objects, each containing: - 'content': The documentation content snippet - 'path': The URL path to the documentation page - 'metadata': Additional metadata about the result
Example Usage for LLM:
When user asks about Wherobots features, functions, or syntax
When generating queries and need context about spatial functions
Example User Queries and corresponding Tool Calls:
User: "How do I use ST_INTERSECTS in Wherobots?"
Tool Call: search_documentation("ST_INTERSECTS spatial function")
User: "What spatial functions are available for distance calculations?"
Tool Call: search_documentation("spatial distance functions")
User: "How do I connect to Wherobots from Python?"
Tool Call: search_documentation("Python connection API")
For the best way to understand how to use spatial SQL in Wherobots, refer to the following Wherobots Documentation:
Writing Effective Spatial Queries in Wherobots: https://docs.wherobots.com/develop/write-spatial-queries
Writing Effective Spatial Queries in Wherobots complete example sub-section: https://docs.wherobots.com/develop/write-spatial-queries#complete-example:-counting-baseball-stadiums-in-the-us
The complete example demonstrates:
Starting the
SedonaContextUsing
wklswhere applicableLoading spatial data from Wherobots tables
Using the correct schema from wherobots_open_data spatial catalogs
Writing spatial SQL queries effectively
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| page_size | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | List of search results |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds context about searching official documentation, returning structured results with content and path, and provides example tool calls. It does not mention rate limits or errors, but these are less critical for a read-only search 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 well-structured with clear sections for purpose, parameters, returns, and examples. It is front-loaded with the main purpose. However, it is slightly verbose with a long block of links and a complete example that could be trimmed without losing clarity.
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 simple tool with only 2 parameters and an existing output schema, the description covers purpose, usage guidelines, parameter details, return structure, and multiple examples. It is comprehensive and leaves little ambiguity.
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?
With 0% schema description coverage, the description fully compensates by explaining the query string, optional page_size with a default of 10, and the automatic injection of ctx. This adds crucial meaning beyond the bare schema.
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 clearly states the tool searches Wherobots documentation for information about spatial functions, syntax, etc. It distinguishes itself from siblings like execute_query_tool and list_catalogs_tool by focusing exclusively on documentation search.
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 explicitly notes it is useful when users need help with Wherobots features or syntax, and provides example user queries and corresponding tool calls. It implicitly distinguishes from siblings, but lacks explicit statements about when not to use it (e.g., for executing actual queries).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!