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., "@secoda-analysis-mcp How is Gross Margin calculated?"
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.
A read-only Model Context Protocol (MCP) server for exploring and analysing your Secoda data catalog. Designed for business users who need to discover data, look up metric definitions, and understand data lineage — without any risk of modifying the catalog.
Zero write access — completely safe to use; nothing in Secoda can be changed
AI chat — ask Secoda's AI natural language questions about your data
Semantic search — find tables, columns, dashboards, and documentation by keyword
Glossary & definitions — browse business term definitions
Data lineage — trace where data comes from and where it flows downstream
Browse collections & Q&A — explore organised resource groups and previously answered questions
Related MCP server: starrocks-mcp
Tool | Purpose |
| Ask Secoda AI a natural language question (supports multi-turn conversations) |
| Find tables, columns, charts, and dashboards by keyword |
| Find docs, glossary terms, and Q&A by keyword |
| Get full details of any entity by its Secoda ID |
| Get full details of a catalog resource (table, column, view) by ID |
| Browse and filter resources using structured criteria |
| Trace upstream/downstream data flow for any entity |
| Browse all business term definitions in the workspace |
| Browse organised groups of resources |
| Get details of a specific collection |
| Browse previously asked and answered Q&A threads |
| Read a specific question and its answer |
Python 3.10+
A Secoda account with API access
A Secoda API token (read permissions are sufficient)
Generate a token at Secoda → Settings → API. Read permissions are sufficient.
No manual install needed — your MCP client runs the server automatically via uvx.
Claude Desktop — add to claude_desktop_config.json:
{
"mcpServers": {
"secoda-analysis": {
"command": "uvx",
"args": ["secoda-analysis-mcp"],
"env": {
"API_TOKEN": "your-secoda-api-token"
}
}
}
}Cursor — add to .cursor/mcp.json:
{
"mcpServers": {
"secoda-analysis": {
"command": "uvx",
"args": ["secoda-analysis-mcp"],
"env": {
"API_TOKEN": "your-secoda-api-token"
}
}
}
}pip install secoda-analysis-mcpThen replace the uvx block above with "command": "secoda-analysis-mcp" and "args": [].
A .mcpb (MCP Bundle) is a ZIP archive that Claude Desktop installs via drag-and-drop — no manual config editing required. The bundle auto-installs all Python dependencies on first run; the only prerequisite is Python 3.9+.
Two manifests live in bundle/:
File | Purpose | Git |
| Generic — prompts the user for credentials at install time via Claude's UI | Committed |
| Org-specific — credentials hardcoded for silent deployment | Gitignored — never commit |
Building an org bundle:
# 1. Create your org manifest (one-time setup)
cp bundle/manifest.template.json bundle/manifest.jsonEdit bundle/manifest.json and set your values in mcp_config.env:
"env": {
"API_TOKEN": "your-secoda-api-token",
"API_URL": "https://your-org.secoda.co/api/v1/",
"AI_PERSONA_ID": "your-persona-uuid"
}AI_PERSONA_ID is optional — omit it to use the workspace default persona.
# 2. Build the bundle
chmod +x bundle/build.sh
./bundle/build.sh
# → dist/miinto-secoda-analyst.mcpb (gitignored)Distributing: Share dist/*.mcpb with colleagues. They drag-and-drop it onto Claude Desktop → Settings → Developer. Works on macOS and Windows.
Security:
bundle/manifest.jsonanddist/are both gitignored. Only the credential-free template is committed. Never add credentials to any file tracked by git.
Variable | Description | Default |
| Your Secoda API token (required) | — |
| Secoda API base URL |
|
| Secoda AI persona ID — pins a specific persona for all | workspace default |
ai_chat(prompt="How is Gross Margin calculated and what tables does it use?")# 1. Find the table
search_data_assets(query="order lines")
# 2. Get full details (columns, description, tags)
get_resource(resource_id="<id-from-search>", truncate_length=None)# Find the entity first
search_data_assets(query="my_important_table")
# Then trace its lineage
entity_lineage(entity_id="<id-from-search>")Apache License 2.0 — see LICENSE for details.
Clone the repo and install all dependencies (including dev tools) with uv:
git clone https://github.com/mbrummerstedt/secoda-analysis-mcp.git
cd secoda-analysis-mcp
uv sync --extra devCopy .env.example to .env and fill in your credentials:
cp .env.example .envsecoda-analysis-mcp/
├── src/
│ └── secoda_analysis/ # Main package
│ ├── __init__.py
│ ├── __main__.py # python -m secoda_analysis entrypoint
│ ├── server.py # FastMCP server setup and tool registration
│ ├── prompt.py # MCP system prompt (tool guidance for the LLM)
│ ├── core/
│ │ ├── client.py # HTTP client with retry logic
│ │ ├── config.py # Environment variable configuration
│ │ └── models.py # Pydantic models (filter/sort validation)
│ └── tools/
│ ├── ai_chat.py # AI chat tool (submit + poll)
│ ├── collections.py # list_collections, get_collection
│ ├── entity.py # retrieve_entity, entity_lineage, glossary
│ ├── questions.py # list_questions, get_question
│ ├── resources.py # list_resources, get_resource
│ └── search.py # search_data_assets, search_documentation
├── tests/
│ ├── conftest.py # Root fixtures (env var defaults)
│ ├── mock/ # Unit tests — all HTTP calls mocked
│ │ ├── conftest.py # Shared mock fixtures and response payloads
│ │ ├── test_client.py
│ │ ├── test_models.py
│ │ ├── test_prompt.py
│ │ ├── test_tools_ai_chat.py
│ │ ├── test_tools_collections.py
│ │ ├── test_tools_entity.py
│ │ ├── test_tools_questions.py
│ │ ├── test_tools_resources.py
│ │ └── test_tools_search.py
│ └── integration/ # Integration tests — hit the real Secoda API
│ ├── conftest.py # Auto-skip when API_TOKEN is not set
│ ├── test_ai_chat.py
│ ├── test_collections.py
│ ├── test_entity.py
│ ├── test_questions.py
│ ├── test_resources.py
│ └── test_search.py
├── pyproject.toml
├── .env.example
└── .python-versionLLM / MCP client
│ MCP protocol (stdio)
▼
server.py ──── registers tools from tools/*.py
│
├── tools calling Secoda AI MCP endpoint
│ tools/search.py, entity.py
│ │
│ └── core/client.py call_tool()
│ │
│ └── POST {API_URL}/ai/mcp/tools/call/
│
├── tools making direct REST calls
│ tools/resources.py, collections.py, questions.py
│ │
│ └── core/client.py _make_request_with_retry()
│ │
│ └── GET {API_URL}/resource/... etc.
│
└── ai_chat tool (submit + poll)
tools/ai_chat.py
│
└── POST/GET {base_url}/ai/embedded_prompt/All tools are read-only — there are no write, update, or delete operations.
Mock tests (no credentials required, fast):
uv run pytest tests/mock/ -vIntegration tests (requires a valid API_TOKEN in your .env):
uv run pytest tests/integration/ -vIntegration tests hit the live Secoda API. The
ai_chattests are slow (30–120s each) as they wait for the AI to respond.
All tests:
uv run pytest -vIntegration tests are automatically skipped when API_TOKEN is not set.
This project uses Ruff for linting and formatting, and mypy for type checking.
# Lint
uv run ruff check src/ tests/
# Format
uv run ruff format src/ tests/
# Type check
uv run mypy src/Start an AI chat session in Secoda and wait for the response.
Submits a prompt to the Secoda embedded AI endpoint and polls until the
response is complete. Sends MCP progress notifications at each poll interval
so clients can show elapsed time. Returns the AI's response text along with
the chat ID, which can be passed as `parent` in a follow-up call to continue
the conversation.
Args:
prompt: The message or question to send to the Secoda AI.
ctx: MCP context (injected by FastMCP; not part of the tool schema).
parent: Chat ID of a previous conversation to continue (optional).
Pass the chat_id from a previous ai_chat response to maintain context.
persona_id: Persona ID to use for the AI chat (optional).
Defaults to AI_PERSONA_ID env var if set, otherwise the workspace default persona.
poll_interval_seconds: Seconds between polling attempts (default: 10).
timeout_seconds: Maximum seconds to wait for completion (default: 360).
Returns:
JSON with keys:
- success: true
- chat_id: The ID of this chat (use as `parent` in follow-up calls)
- status: "completed"
- response_content: The AI's response text
Example:
# Start a new conversation
ai_chat(prompt="How do we handle price reductions in GMV calculations?")
# Continue a previous conversation
ai_chat(
prompt="Can you elaborate on the discount logic?",
parent="0d53d57b-d1ef-4fc2-bc50-fd3fba2fea93"
)
Error handling:
- 403: Permission denied - check API token has AI chat permissions
- 429: Rate limit exceeded - tool retries automatically
- Timeout: Increase timeout_seconds if the AI takes longer than expected| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The message or question to send to the Secoda AI | |
| parent | No | Chat ID of a previous conversation to continue. Use the chat_id returned from a previous ai_chat call to maintain conversation context. | |
| persona_id | No | Persona ID to use for the AI chat. Defaults to the AI_PERSONA_ID environment variable if set, otherwise the workspace default persona is used. | |
| poll_interval_seconds | No | Seconds between polling attempts while waiting for the AI to respond (default: 10) | |
| timeout_seconds | No | Maximum seconds to wait for the AI to complete the response (default: 360) |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Disclosures beyond annotations: polling with progress notifications, continuation via parent, return structure, error handling (403, 429, timeout), and that ctx is injected by FastMCP. Annotations (openWorldHint=true) are consistent with non-idempotent chat 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?
Well-structured: summary line, then parameters with defaults, return format, example, and error handling. Each section is concise and front-loaded. No redundant 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?
Complete for a tool with 5 parameters, polling, continuation, and error handling. The description covers all aspects: how to start, continue, handle errors, and what to expect as output. Output schema is implied in the returns section.
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 baseline is 3. Description adds value by explaining the purpose of each parameter (e.g., parent usage, persona defaults, polling/timeout defaults) and provides usage context beyond schema descriptions.
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 verb 'start', resource 'AI chat session', and action 'wait for response'. It distinguishes this tool from sibling tools which are about data retrieval and entity lineage, not AI chat.
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 context for when to use the tool, including examples for starting and continuing conversations. Error handling with specific HTTP codes and automatic retries is included. No explicit 'when not to use' statement, but sibling tools imply alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the upstream and downstream lineage of an entity.
Args:
entity_id: The ID of the entity to get lineage for
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
Entity lineage with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | The ID of the entity to get lineage for | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | 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. It discloses the truncation behavior (truncate_length parameter and return truncation), but does not mention error handling, performance, or permissions. Adequate but 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?
The description is short and front-loaded with the main purpose. The Args/Returns section adds structure. It could be slightly more concise, but overall efficient.
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 tool has an output schema, but the description only mentions truncation. For a lineage tool, it could specify the direction (upstream/downstream is already stated) or expected structure. The description is adequate but not rich.
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%, with both parameters having descriptions. The description repeats the same information (entity_id, truncate_length, default 150), adding no new 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 retrieves 'upstream and downstream lineage' for an entity, using a specific verb and resource. This distinguishes it from sibling tools like get_entity or get_resource which fetch a single entity, not its lineage.
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 explains what the tool does but provides no guidance on when to use it versus alternatives like retrieve_entity or search_data_assets. No explicit when-not or comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific collection by its ID.
Use this to get full details about a collection after finding it via list_collections.
Args:
collection_id: The unique identifier of the collection
truncate_length: Maximum characters for text fields in results (default: 150).
Set to None for full descriptions.
Returns:
Collection details with text fields truncated to specified length
Example:
get_collection(collection_id="collection-123")| Name | Required | Description | Default |
|---|---|---|---|
| collection_id | Yes | The unique identifier of the collection | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses truncation behavior for text fields, default length, and option for full descriptions. It doesn't mention read-only nature, but 'Retrieve' implies it.
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 concise, well-structured with purpose, usage, args, returns, and example. No wasted words, 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?
The description fully covers the tool's behavior given an output schema exists. It explains the key nuance of truncation and provides a complete example.
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%. The description adds value by explaining 'Set to None for full descriptions' for truncate_length, which is not in the schema's anyOf description.
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 'Retrieve a specific collection by its ID' and explicitly distinguishes from sibling tool 'list_collections' by advising to use this after finding the collection via list_collections.
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 explicit context: 'Use this to get full details about a collection after finding it via list_collections.' This tells the agent exactly when to invoke this tool, including a specific alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific question and its answer by ID.
Use this to read the full content of a question and any accepted answers after
finding it via list_questions or search_documentation.
Args:
question_id: The unique identifier of the question
truncate_length: Maximum characters for text fields in results (default: 150).
Set to None to read the full question and answer text.
Returns:
Question details including title, description, and answers| Name | Required | Description | Default |
|---|---|---|---|
| question_id | Yes | The unique identifier of the question | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It clearly indicates a read operation ('Retrieve', 'read'), describes the truncate_length parameter, and mentions the return structure. However, it does not explicitly state that there are no side effects or auth requirements.
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 concise with 5 sentences, front-loaded with the primary purpose, and efficiently covers usage, parameters, and return values without unnecessary detail.
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 that an output schema exists (as indicated by context), the description adequately covers the tool's purpose, parameters, and when to use it. It also provides guidance on truncation, making it complete for the tool's complexity.
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% (both parameters described), so baseline is 3. The description adds value by explaining the effect of setting truncate_length to None, which provides actionable guidance 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 explicitly states 'Retrieve a specific question and its answer by ID,' which is a clear verb+resource combination. It differentiates from siblings by mentioning usage after list_questions or search_documentation.
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 advises using this tool after finding the question via list_questions or search_documentation, providing context. While it doesn't explicitly list when not to use, the guidance is helpful and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve a specific resource by its ID.
Use this to get full details of a catalog resource (table, column, view, etc.)
after finding it through list_resources or search_data_assets.
Args:
resource_id: The unique identifier of the resource to retrieve
truncate_length: Maximum characters for text fields in results (default: 150).
Set to None when you need full descriptions/definitions.
Returns:
Resource details with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| resource_id | Yes | The unique identifier of the resource to retrieve | |
| truncate_length | No | Maximum characters for text fields in results. Set to None for full descriptions/definitions |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains truncation behavior and return value, but does not explicitly state that the operation is read-only. However, the action word 'Retrieve' implies no side effects, and the description is otherwise transparent about parameters and results.
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?
Description is concise with structured Args/Returns sections. Each sentence serves a purpose. Could be slightly tighter by removing default mention in description since schema already has default, but overall good.
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 output schema exists and sibling tools context, the description covers usage, parameters, and return value adequately. Missing explicit mention of permissions or rate limits, but these are not critical for a retrieval tool. High completeness for the context.
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 covers both parameters with descriptions (100% coverage). Description adds context about truncate_length default and setting to None for full descriptions, but this is complementary rather than essential beyond what schema provides. Baseline 3 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 clearly states 'Retrieve a specific resource by its ID' and specifies it is for catalog resources like table, column, view. This distinguishes it from sibling tools like list_resources (listing) and search_data_assets (searching).
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 says 'Use this to get full details ... after finding it through list_resources or search_data_assets,' providing clear when-to-use and implicitly when-not-to-use (e.g., not for listing or searching).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve all business term definitions from the workspace glossary.
Args:
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
Glossary with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 truncation behavior but does not mention that it is a read-only operation, potential performance impact, or any side effects. The behavior is partially 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?
The description is concise with only three sentences, each adding value. It uses a clear structure with Args and Returns sections, and front-loads the main action immediately.
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 read tool with one optional parameter and an output schema, the description is largely complete. However, it does not mention pagination or size limits for the glossary, which might be important for large glossaries.
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%, and the description adds the default value and return structure (truncated fields), which provides additional context beyond the schema alone. The parameter meaning is clear.
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 verb 'Retrieve' and the resource 'workspace glossary', and it distinguishes itself from siblings like ai_chat or entity_lineage by focusing on business term definitions.
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 does not provide any guidance on when to use this tool versus alternatives. It lacks context about prerequisites, limitations, or when to prefer glossary over similar tools like list_resources.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all collections in the workspace.
Collections are organized groups of related resources (tables, dashboards, documents).
Use this to browse what topic areas and resource groups exist.
Args:
title: Filter collections by title (optional)
page: Page number for pagination (default: 1)
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
List of collections with text fields truncated to specified length
Example:
list_collections(title="Customer")
list_collections(page=2)| Name | Required | Description | Default |
|---|---|---|---|
| title | No | Filter collections by title (optional) | |
| page | No | Page number for pagination | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | 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. It explains filtering, pagination, and truncation behavior, but does not disclose whether the operation is read-only (likely), required permissions, or any potential side effects. Adequate but not fully 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?
The description is well-structured with Args, Returns, and Example sections. It is front-loaded with the core purpose. Minor redundancy with schema descriptions, but overall efficient.
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 presence of an output schema (handling return values), the description covers all necessary aspects: purpose, parameters, and usage example. No gaps identified.
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 100%, so the description adds minimal value beyond repeating parameter info. It provides an example usage, which helps illustrate how parameters combine, but does not explain them in more depth than 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 collections in the workspace' and explains what collections are (organized groups of related resources). It distinguishes from sibling tools like get_collection (single collection) and list_questions/list_resources (different resource types).
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 'Use this to browse what topic areas and resource groups exist,' providing clear context for when to use it. It does not explicitly state when not to use it or mention alternatives, but the purpose is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all questions in the workspace.
Questions in Secoda represent data consumer inquiries that have been asked and
answered by the data team. Use this to find existing answers before asking
a new question.
Args:
page: Page number for pagination (default: 1)
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
List of questions with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses pagination and truncation behavior, and implies read-only nature. Lacks explicit mention of authentication or performance, but sufficient for a listing 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?
Concise, front-loaded with main purpose, followed by brief domain context and parameter descriptions. No unnecessary 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?
Covers purpose, usage, and parameters. Since output schema exists, return value explanation is adequate. Could add details about ordering or error handling, but overall sufficient.
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%, but description adds meaning by explaining that 'page' controls pagination and 'truncate_length' limits text field lengths in results, providing context beyond 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?
Description clearly states 'List all questions in the workspace' with specific verb and resource. Explains what questions are in Secoda, distinguishing from sibling 'get_question'.
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?
Explicitly says 'Use this to find existing answers before asking a new question.' Provides clear usage context but does not explicitly mention when not to use or alternatives like 'get_question'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List catalog resources with advanced filtering capabilities.
This endpoint provides precise control over resource queries using structured filters.
Use this when you need exact matching, specific field filtering, or complex queries.
Args:
filter: FilterOperand (field or logical) for filtering resources
sort: SortConfig for ordering results
page: Page number for pagination (default: 1)
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
Paginated list of resources matching the filter criteria
Filter Examples:
# Single condition - title contains
filter = {"operator": "contains", "field": "title", "value": "order_lines"}
# Single condition - entity type
filter = {"operator": "exact", "field": "native_type", "value": "table"}
# Find all columns of a specific table
filter = {"operator": "exact", "field": "parent_id", "value": "table-id-123"}
# Multiple conditions with AND
filter = {
"operator": "and",
"operands": [
{"operator": "exact", "field": "native_type", "value": "table"},
{"operator": "contains", "field": "title", "value": "customer"}
]
}
Sort Examples:
# Sort by title ascending
sort = {"field": "title", "order": "asc"}
# Sort by external_usage descending (most popular first)
sort = {"field": "external_usage", "order": "desc"}| Name | Required | Description | Default |
|---|---|---|---|
| filter | No | Filter dictionary for filtering resources. Can be either a field filter or logical filter. Field filter example: {"operator": "exact", "field": "title", "value": "my_table"} Logical filter example: {"operator": "and", "operands": [{"operator": "exact", "field": "native_type", "value": "table"}, {"operator": "contains", "field": "title", "value": "order"}]} PARENT/CHILD RELATIONSHIPS (COMMON PATTERN): - Filter by parent_id to find ALL columns of a table: {"operator": "exact", "field": "parent_id", "value": "table-id-123"} Available field operators: "exact", "contains", "in", "is_set" Available logical operators: "and", "or", "not" | |
| sort | No | Sort configuration dictionary for ordering results. Example: {"field": "title", "order": "asc"} With tie breaker: {"field": "updated_at", "order": "desc", "tie_breaker": {"field": "created_at", "order": "desc"}} | |
| page | No | Page number for pagination | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It details the tool's behavior: listing with filtering, sorting, pagination, and truncation. Filter examples and sort examples are given. No side effects are mentioned, but as a list operation, none are expected.
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 long with extensive examples. While valuable, it could be more concise. The 'Args:' section largely repeats schema information. The structure is logical, but the length could be reduced 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 tool's complexity (4 parameters, filtering, sorting, pagination) and the presence of an output schema, the description is comprehensive. It covers all needed use cases with examples, making it fully adequate for an AI agent.
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%, but the description adds significant value beyond the schema, especially for complex parameters. It provides multiple filter examples (including parent/child relationships) and sort examples, which help an AI agent construct correct parameters. For page and truncate_length, it reinforces defaults already in 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 catalog resources with advanced filtering capabilities,' specifying the action (list) and resource (catalog resources). It distinguishes itself from siblings like get_resource (single resource) and search_data_assets (broader search) through the description.
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 says 'Use this when you need exact matching, specific field filtering, or complex queries,' providing clear guidance on when to use. It does not mention when not to use or direct alternatives like get_resource, but the context of sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve an entity from the catalog by ID.
Args:
entity_id: The ID of the entity to retrieve
truncate_length: Maximum characters for text fields in results (default: 150).
Often useful to set to None when you need full descriptions/definitions.
Returns:
Entity details with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| entity_id | Yes | The ID of the entity to retrieve | |
| truncate_length | No | Maximum characters for text fields in results. Often useful to set to None when you need full descriptions/definitions |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses truncation behavior and default value, which is key behavioral context. No annotations provided, so description carries full burden. Lacks details on error handling (e.g., invalid ID) or response structure beyond 'Entity 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?
Extremely concise: two sentences plus args/returns bullet. Front-loaded purpose, no fluff.
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?
Adequate for a simple retrieval tool with output schema. Explains truncation behavior but misses error states and does not address sibling context. Could be more complete given no annotations.
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 baseline is 3. Description rephrases schema descriptions but adds practical note on setting truncate_length to None for full content. Minimal added value beyond 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?
Clearly states it retrieves an entity by ID, with parameters explained. However, does not differentiate from sibling get_* tools like get_collection, get_question, get_resource, which also retrieve specific items by ID. The generic term 'entity' is ambiguous.
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 truncation usage hints but no guidance on when to use this tool vs alternatives like search_data_assets or list tools. No when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for data assets in the catalog.
Args:
query: Search query for finding tables, columns, charts, dashboards
page: Page number for pagination (default: 1)
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
Search results with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for finding tables, columns, charts, dashboards | |
| page | No | Page number for pagination | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description states it returns truncated search results but does not explicitly declare it as read-only or disclose any other behavioral traits beyond what the schema implies.
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 concise, front-loaded with the purpose, and includes a structured args section. Every sentence adds value without fluff.
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 that an output schema exists and the tool is a simple search, the description covers the essential functionality and parameters. However, it could mention the scope of the catalog or pagination behavior.
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 already provides full descriptions for all three parameters. The description adds marginal value by listing defaults, but largely duplicates 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 'Search for data assets in the catalog' and lists specific asset types (tables, columns, charts, dashboards), which distinguishes it from sibling tools like search_documentation and get_resource.
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 no guidance on when to use this tool versus its siblings. It does not mention context, prerequisites, or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for documentation in the catalog.
Args:
query: Search query for finding documents, questions, glossary terms
page: Page number for pagination (default: 1)
truncate_length: Maximum characters for text fields in results (default: 150)
Returns:
Search results with text fields truncated to specified length| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Search query for finding documents, questions, glossary terms | |
| page | No | Page number for pagination | |
| truncate_length | No | Maximum characters for text fields in results |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that results have text fields truncated to a specified length, but does not mention any behavioral traits like read-only nature, auth needs, or potential side effects. For a search tool, read-only is implied but not stated.
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 concise and well-structured with Args and Returns sections. Every sentence serves a purpose, no extraneous information. Front-loaded with the 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?
For a search tool with 3 parameters and no output schema, the description is complete. It explains the purpose, parameters (with defaults and constraints), and the return behavior (truncation). No obvious gaps given the tool's complexity.
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 100% coverage, so baseline is 3. The description repeats the schema's parameter descriptions without adding new semantics, such as query syntax or formatting rules. No additional value 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 'Search for documentation in the catalog', specifying a concrete verb and resource. It distinguishes from sibling 'search_data_assets' which presumably searches data assets, making the purpose unambiguous.
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 provided on when to use this tool versus alternatives like 'search_data_assets' or when not to use it. The description only states what the tool does, without usage context.
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.
v0.3.3ai_chatentity_lineageget_collectionget_questionget_resourceglossarylist_collectionslist_questionslist_resourcesretrieve_entitysearch_data_assetssearch_documentationScored across 12 tools
Most tools have distinct purposes, but 'get_resource' and 'retrieve_entity' overlap significantly, both retrieving a catalog item by ID. This creates ambiguity for an agent about which to use.
Most tools follow a verb_noun pattern (e.g., get_collection, list_resources), but 'entity_lineage' and 'glossary' are noun-only names, breaking consistency. The pattern is mostly readable but not uniform.
With 12 tools, the set is well-scoped for a data catalog analysis server. It covers listing, retrieval, search, and AI chat without being bloated.
The tools cover core read operations (list, get, search) and AI chat, but miss a dedicated tool to retrieve a single glossary term by ID. For an analysis server, this is a minor gap.
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
Governed data discovery, exact queries, decisions, simulations, and runtime utilities over MCP.
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
