F
licenseNot graded
qualityD
maintenanceFacilitates note storage and summarization through custom URIs, allowing users to manage, summarize, and update notes with varying detail levels in a collaborative environment.
-
dandi-query-server
by bendichter
Click on "Install 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., "@dandi-query-serverCreate a note about the motor cortex findings from DANDI Archive"
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.
dandi-query-server MCP Server
Enables complex queries over data on the DANDI Archive
This is a TypeScript-based MCP server that implements a simple notes system. It demonstrates core MCP concepts by providing:
Resources representing text notes with URIs and metadata
Tools for creating new notes
Prompts for generating summaries of notes
Features
Resources
List and access notes via
note://URIsEach note has a title, content and metadata
Plain text mime type for simple content access
Tools
create_note- Create new text notesTakes title and content as required parameters
Stores note in server state
Prompts
summarize_notes- Generate a summary of all stored notesIncludes all note contents as embedded resources
Returns structured prompt for LLM summarization
Related MCP server: MCP Index Notes
Development
Install dependencies:
npm installBuild the server:
npm run buildFor development with auto-rebuild:
npm run watchInstallation
To use with Claude Desktop, add the server config:
On MacOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
{
"mcpServers": {
"dandi-query-server": {
"command": "/path/to/dandi-query-server/build/index.js"
}
}
}Debugging
Since MCP servers communicate over stdio, debugging can be challenging. We recommend using the MCP Inspector, which is available as a package script:
npm run inspectorThe Inspector will provide a URL to access debugging tools in your browser.
Available Tools
7 toolsexecute_sqlC
Execute advanced SQL queries against the DANDI database
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to execute (SELECT statements only, max 10,000 chars) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It only says 'execute advanced SQL queries', which implies a read operation from the schema constraint (SELECT only) but does not explicitly state it is safe (no writes), nor discloses any rate limits, timeout, or result size behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words. However, the description is too brief and could include more crucial info without being lengthy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 and one parameter, the description omits important context such as return format (e.g., list of rows), whether results are paginated, and any performance implications. Given the sibling set including validation and schema tools, the description is incomplete for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the sql parameter description including key constraints (SELECT only, max 10,000 chars). The tool description adds 'advanced' but no further meaning. Baseline 3 is appropriate as description complements schema but doesn't add much beyond.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it executes advanced SQL queries against the DANDI database, with verb 'execute' and resource 'advanced SQL queries'. However, it does not differentiate from sibling tool 'validate_sql', which also deals with SQL queries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like validate_sql, search_assets, or search_datasets. Doesn't mention that validate_sql should be used first to test queries, or that this tool is for complex queries beyond simple filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_filter_optionsA
Get available filter options for basic search
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided so description must disclose behavior. It is a simple read operation (get) with no parameters, making effects obvious. Could mention return type (list of filter criteria) but not essential.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but for a simple get operation with zero parameters, description is mostly complete. Could specify that it returns available filter options, but the purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, schema coverage 100%. Description adds no parameter info, but baseline 4 is appropriate since no params need explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get available filter options for basic search' - a specific verb and resource. It distinguishes from sibling tools like search_assets and search_datasets by providing filter options rather than performing searches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates 'for basic search' implying use before searching, but no explicit when/when-not or alternatives. The context is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_full_schemaA
Get complete database schema with all tables and their columns
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description lacks behavioral details such as permissions required, performance considerations, or whether the result is static or dynamic. For a tool with no annotations, the description should disclose more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete enough for a simple schema retrieval tool with no parameters, but it lacks explanation of return format, scope, or any side effects, which could be relevant for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters and schema coverage at 100%, the description doesn't need to add parameter details. Baseline for zero parameters is 4, and the description is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the complete database schema with all tables and columns, distinguishing it from the sibling 'get_schema' by emphasizing completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 get_schema, execute_sql, or search_assets. The description only states what it does, not when it's appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_schemaC
Get database schema information
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| table | No | Specific table name to get details for (optional) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. The description does not disclose behavioral traits like read-only nature, permissions required, or any side effects. It merely states the function without elaboration.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words. However, it could be more informative without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one optional parameter, no output schema), the description is minimally adequate. However, it lacks context on return value structure and sibling tool differentiation, which is important for the agent to correctly select this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning beyond the schema, which already details the optional 'table' parameter. No further semantics are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get database schema information' which clearly identifies the tool's purpose. However, it does not differentiate from sibling tools like get_full_schema, which may have overlapping functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_full_schema or execute_sql. The agent has no context to decide which tool is appropriate for a given query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_assetsB
Search DANDI assets (files/sessions) using basic filters
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results (default: 20, max: 100) | |
| offset | No | Number of results to skip for pagination | |
| species | No | Filter by species | |
| dandiset_id | No | Filter by specific dataset ID | |
| session_type | No | Filter by session type | |
| variable_measured | No | Filter by variables measured (e.g., ['ElectricalSeries']) |
TDQS
B3.4/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. However, it only states the basic purpose without mentioning rate limits, error handling, response format, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that clearly communicates the tool's purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema and annotations, the description lacks details on return values, pagination behavior beyond limit/offset, and potential side effects. It is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with all parameters having descriptions. The description adds no additional meaning beyond 'using basic filters', so it meets the baseline but does not enhance understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'DANDI assets' with clarification 'files/sessions'. It distinguishes from siblings like search_datasets and execute_sql by specifying 'basic filters'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'basic filters' but does not provide explicit guidance on when to use this tool versus alternatives such as search_datasets or execute_sql. No when-not-to-use criteria or prerequisites are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_datasetsC
Search DANDI datasets using basic filters
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Search in dataset names | |
| limit | No | Maximum number of results (default: 20, max: 100) | |
| offset | No | Number of results to skip for pagination | |
| anatomy | No | Filter by anatomical region (e.g., ['hippocampus', 'cortex']) | |
| species | No | Filter by species (e.g., ['Mus musculus', 'Rattus norvegicus']) | |
| approach | No | Filter by experimental approach (e.g., ['electrophysiology']) | |
| description | No | Search in dataset descriptions | |
| measurement_technique | No | Filter by measurement technique (e.g., ['extracellular electrophysiology']) |
TDQS
C2.9/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Search' but does not confirm read-only nature, discuss pagination beyond the schema, or mention authentication or rate limits. The behavioral disclosure is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized but could be expanded slightly to add value without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters and no output schema or annotations, the description lacks critical context such as what the tool returns, how filters combine, and where to find valid filter values. The sibling get_filter_options suggests a need for more integration guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds only the generic phrase 'basic filters', which does not enhance understanding beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'search' and the resource 'DANDI datasets', indicating a search operation. However, it does not differentiate from the sibling tool search_assets, which may also search datasets or related content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies basic filtering but provides no explicit guidance on when to use this tool versus alternatives like get_filter_options or execute_sql. No exclusion criteria or context for decision-making is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_sqlA
Validate SQL query without executing it
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL query to validate |
TDQS
A3.5/5.0
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states that the tool validates without executing. It does not disclose what constitutes a validation outcome (e.g., syntax vs. semantic checks), error behavior, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is front-loaded and conveys the essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is adequate but lacks details on what the validation result includes (e.g., boolean, error messages), which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'sql' described as 'SQL query to validate'. The description adds no additional meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('validate') and resource ('SQL query'), and explicitly contrasts with execution. This distinguishes it from the sibling 'execute_sql' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose implies use for validation rather than execution, but there is no explicit guidance on when to use this tool versus alternatives like 'execute_sql' or other validation methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
7 tool updates
v0.1.0- First observed
execute_sql - First observed
get_filter_options - First observed
get_full_schema - First observed
get_schema - First observed
search_assets - First observed
search_datasets - First observed
validate_sql
TDQS
A3.5/5.0
Disambiguation4/5
Most tools have distinct purposes, but `get_schema` and `get_full_schema` overlap significantly. The descriptions differ in wording but not in clear behavioral distinction, which could confuse an agent.
Naming Consistency5/5
All tool names follow a consistent `verb_noun` pattern (e.g., `execute_sql`, `search_datasets`). Even `get_full_schema` adheres to this pattern with an adjective inserted. No mixing of conventions.
Tool Count5/5
Seven tools cover querying, schema exploration, and validation. This is a well-scoped set for a database query server—enough tools to be useful without overwhelming the user.
Completeness4/5
The tool set covers core query, schema, and search needs. Missing conveniences like direct single-resource lookup by ID, but SQL can compensate. Minor gap in not having a tool for retrieving specific dataset details without SQL.
Maintenance
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
- Dexi NotesOAuthnet.dexi
Search and manage your Dexi notes: full-text and semantic search, tags, folders, spaced repetition.
- KnowtisOAuthapp.knowtis
Create, search and manage Knowtis collaborative notes from AI assistants.
- TaprootOAuthcom.taproothq
Persistent memory layer for AI tools. Save and recall notes across Claude and other MCP clients.
Cross-session, cross-device memory for your agent: remember and recall notes. No key to start.
Related MCP Servers
- FlicenseBqualityDmaintenanceEnables indexing and retrieving notes with full-text search using SQLite, plus building knowledge graphs to find relationships between concepts. Supports natural language note management, tagging, and semantic connections.16-
- FlicenseCqualityNot gradedmaintenanceEnables creating and managing text notes with a simple note-taking system. Provides tools to create notes, access them via URIs, and generate summaries of all stored notes.41-
- FlicenseAqualityDmaintenanceEnables AI assistants to manage a personal markdown-based knowledge base with natural language interactions. Supports creating, searching, updating, and organizing notes across categories like people, recipes, meetings, and procedures.111-
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/bendichter/dandi-query-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server