VirtualFlyBrain
Server Details
MCP server for Drosophila neuroscience data from VirtualFlyBrain
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- Robbie1977/VFB3-MCP
- GitHub Stars
- 0
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.8/5 across 8 of 8 tools scored.
Each tool has a distinct, well-defined purpose. There is no overlap: hierarchy building, term info, dataset listing, connectivity queries, entity resolution for split-GAL4 and general FlyBase, pre-computed queries, and term search are all clearly separated.
All tools use consistent snake_case and follow a verb_noun pattern (get_, list_, query_, resolve_, run_query, search_terms). The naming is predictable and aids understanding.
With 8 tools, the server is well-scoped for the domain of Drosophila brain connectomics. Each tool serves an essential function without redundancy or unnecessary bloat.
The tool surface covers the full workflow: term discovery (search_terms), term details (get_term_info, get_hierarchy), entity resolution (resolve_entity, resolve_combination), connectivity queries (query_connectivity), and pre-computed queries (run_query). All typical user goals are addressable.
Available Tools
8 toolsget_hierarchyAInspect
Build a hierarchy tree for a VFB term, showing ancestors (parents) and/or descendants (children). Use relationship "part_of" for brain region structure (e.g. "what are the parts of the mushroom body?") and "subclass_of" for cell type hierarchies (e.g. "what types of Kenyon cell are there?"). Descendants are returned as a nested tree for both relationship types. Ancestors are returned as a nested chain, filtered to nervous system terms for part_of. Start with max_depth=1 for direct parents/children, and offer to go deeper if the user wants more detail.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | VFB term ID (e.g. FBbt_00005801 for mushroom body, FBbt_00003686 for Kenyon cell) | |
| direction | No | Which direction to explore (default: "both") | both |
| max_depth | No | Number of levels to expand. 1 = direct children/parents only. Higher values go deeper. -1 = full tree (use with caution on broad terms). Default: 1. | |
| relationship | Yes | Type of hierarchy: "part_of" for brain region structure, "subclass_of" for cell type taxonomies |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. It reveals that descendants are a nested tree, ancestors are a nested chain filtered for part_of, and explains max_depth behavior. Additional details on error handling or performance would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph of four sentences, front-loaded with the core purpose. Every sentence adds essential information without redundancy.
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 params, 2 enums, no output schema), the description covers purpose, relationship usage, output structure, and depth advice. It could explicitly mention the direction parameter's default and output format but remains fairly 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 100%, but the description adds value by explaining the relationship parameter with concrete examples (brain region vs cell type) and providing usage advice for max_depth. This enhances the 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 tool builds a hierarchy tree for a VFB term, showing ancestors and/or descendants. This specific verb+resource combination distinguishes it from sibling tools like get_term_info or query_connectivity.
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 concrete usage examples for relationship types ('part_of' for brain regions, 'subclass_of' for cell types) and advises starting with max_depth=1. However, it does not explicitly state when not to use this tool or recommend alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_term_infoAInspect
Get term info for a VFB or anatomy ontology entity (VFB_*, FBbt_*, etc.). THIS IS THE QUERY DISCOVERY TOOL: the response's "Queries" array lists the valid query_type values that run_query accepts for this entity. ALWAYS call get_term_info before run_query unless you already obtained the query_type from a previous get_term_info call in this conversation. Returns: SuperTypes (classification), Tags (data flags like has_image, has_neuron_connectivity), Queries (valid query_types for run_query), RelatedTools (other MCP tools applicable to this entity, with default_args ready to copy — e.g. get_hierarchy with subclass_of for cell types or part_of for nervous-system regions), Images (keyed by template brain ID), Publications, Synonyms. Supports batch — pass an array of IDs to fetch in parallel; batch results are returned as a JSON object keyed by ID. To build VFB browser URLs from the Images field: https://v2.virtualflybrain.org/org.geppetto.frontend/geppetto?id=&i=,, — id= sets the focus term and i= lists images for the 3D viewer (template ID must be first in i= to set the coordinate space).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | One or more VFB IDs to look up |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it lists all return fields (SuperTypes, Tags, Queries, etc.), explains batch behavior (parallel fetch, JSON keyed by ID), and defines the tool as read-only query discovery. No contradictions.
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 dense but every sentence adds value. Some information (URL construction) could be slightly trimmed, but overall it's well-organized and front-loaded with the most important 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?
Given no output schema, the description thoroughly explains return fields and includes batch behavior, URL building, and inter-tool relationships. It provides all necessary context 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 single parameter 'id' is well-described in the schema, and the description adds critical context about batch support, parallelism, and response format (keyed by ID). This goes beyond schema basics.
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 term info for VFB or anatomy ontology entities, and highlights its primary role as the query discovery tool. It distinguishes itself from siblings like run_query by specifying that this tool must be called first to obtain valid query 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?
Explicitly instructs to always call this before run_query unless query_type is already known. Provides batch usage and URL construction guidance, offering clear when-to-use and how-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_connectome_datasetsAInspect
List available connectome datasets with their labels and symbols. Use the returned symbols when constructing exclude_dbs arguments for query_connectivity. Common datasets include Hemibrain (hb), FAFB (fafb), MANC, and others. Call this tool if unsure which dataset symbols are valid.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies a read-only listing operation (no side effects). It does not explicitly state it is non-destructive, but the nature is clear.
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?
Three sentences front-loaded with purpose, each sentence adds value. No redundancy or 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?
Despite no output schema, the description fully explains what the tool does and its role in a larger workflow. Complete for a simple listing 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?
No parameters (0 params), so baseline 4 per guidelines. Description adds context by explaining the purpose of returned symbols, exceeding the baseline.
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 it lists available connectome datasets with labels and symbols, and specifically ties to use with sibling tool query_connectivity, distinguishing its purpose.
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 advises to call this tool when unsure which dataset symbols are valid, and explains how the returned symbols are used in exclude_dbs arguments for query_connectivity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
query_connectivityAInspect
Query synaptic connectivity between Drosophila neuron classes across ALL connectome datasets simultaneously for comparative connectomics. This is NOT pre-cached — it runs live queries, so expect slow responses (up to several minutes). Set both upstream_type AND downstream_type to filter connections between two specific neuron classes (e.g., "What Tm1→T3 connections exist across all datasets?"). At least one of upstream_type or downstream_type is required. CONSTRAINTS: Only accepts neuron class terms (OWL IDs like FBbt_00003789 or labels like "transmedullary neuron Tm1") — anatomical regions or neuropils (e.g., "lobula", "medulla") are NOT accepted. NOT suitable for individual neuron-to-neuron connections — for pre-computed connections of a single individual neuron, use run_query with NeuronNeuronConnectivityQuery instead. NOT for muscle/sense organ connections. RECOMMENDED DEFAULTS: weight=5, exclude_dbs=["hb","fafb"] unless user specifies otherwise. For both-ends queries, start with weight≥50 to avoid timeouts. WORKFLOW: Confirm parameters with user before querying. Use search_terms with filter_types ["neuron","class"] to validate/canonicalize neuron type labels. If zero results, try relaxation: lower weight to 1, then remove exclude_dbs filter, then try group_by_class=true — report what worked and let user decide. Present large results (>50 rows) as top 20 by weight with summary stats.
| Name | Required | Description | Default |
|---|---|---|---|
| weight | No | Minimum synapse count threshold (recommended default: 5). Lower to 1 if initial query returns zero results as first relaxation step. | |
| exclude_dbs | No | Dataset symbols to exclude (recommended default: ["hb", "fafb"] to focus on newer datasets). Pass empty array [] to include all datasets. Use list_connectome_datasets to see valid symbols. | |
| upstream_type | No | Upstream (presynaptic) neuron class — OWL ID (e.g., "FBbt_00003789") or full label (e.g., "transmedullary neuron Tm1"). Must be a neuron type/class, NOT an anatomical region. Use search_terms with filter_types ["neuron","class"] to validate/canonicalize labels before querying. | |
| group_by_class | No | If true, aggregate results by neuron class — returns total_weight, average_weight, percent_connected per class pair, ranked by pairwise_connections. If false (default), returns individual neuron-to-neuron rows. | |
| downstream_type | No | Downstream (postsynaptic) neuron class — OWL ID or full label. Must be a neuron type/class, NOT an anatomical region. If user asks about connectivity to a brain region, first find neuron classes in that region using search_terms, then query for those classes. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that queries are live and slow (up to several minutes), explains constraints on input types, and recommends defaults. Could mention idempotency or side effects, but overall 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?
Description is thorough but somewhat verbose—the workflow details could be condensed. However, it is well-structured with clear sections and front-loaded purpose. Every sentence adds value, though some redundancy exists.
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 no output schema, the description does not fully explain return format but mentions presentation of large results. It covers constraints, workflow, and validation steps. Could be improved by describing typical response structure.
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 significant context beyond schema: e.g., for weight it explains relaxation strategy, for exclude_dbs it gives defaults and dataset listing tool, for upstream/downstream_type it reinforces neuronal class constraint. This aids correct parameter usage.
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 it queries synaptic connectivity between Drosophila neuron classes across all connectome datasets simultaneously for comparative connectomics. It distinguishes from sibling tools like run_query (individual neuron connections) and search_terms (validation).
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 when-to-use (class-level connectivity across datasets), when-not-to-use (not for individual neuron-to-neuron, not for muscle/sense organ connections), and alternatives (run_query for individual connections). Includes a detailed workflow and recommended defaults.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_combinationAInspect
Resolve an unresolved split-GAL4 combination name or synonym into its FBco ID and component hemidrivers. Pass the raw combination text exactly as the user wrote it (for example "MB002B" or "SS04495"). Do NOT pass an FBco ID; if you already have one, use the downstream tool directly. Uses tiered resolution: exact name → synonym → broad pattern match. Returns FBco ID, combination name, matched synonym (if applicable), and component allele IDs/names. IMPORTANT: When match is via synonym, confirm the resolved combination with the user before proceeding (e.g., "Your search for 'MB002B' matched [formal name] (FBco...) via synonym. Shall I proceed?"). If multiple matches, show disambiguation list and ask user to choose.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unresolved split-GAL4 combination name or synonym exactly as written by the user (e.g., "MB002B", "SS04495"). Do NOT pass an FBco ID here. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully covers resolution strategy (tiered matching), required user confirmation for synonym matches, and disambiguation for multiple matches.
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?
Somewhat lengthy but each sentence contributes distinct value; structured with main action, usage instructions, behavior notes, and important caveats.
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 no output schema, description adequately explains return content (ID, name, synonym, components), all edge cases (synonym match, multiple matches), and required user interaction.
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?
Single parameter with 100% schema coverage; description adds usage nuance (exact text, do not pass FBco ID) and examples, exceeding schema alone.
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 specifies verb (resolve) and distinct resource (split-GAL4 combination names/synonyms to FBco ID and components).
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 instructs to pass raw user text, not FBco ID; provides alternative tool direction; details confirmation and disambiguation procedures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolve_entityAInspect
Resolve an unresolved FlyBase-related query string into VFB/FlyBase IDs and metadata. Pass the raw text exactly as the user wrote it (for example "P{VT054895-GAL4.DBD}", "Hb9-GAL4", "SS04495", "MB002B", "PAM cluster", or "dpp"). Do NOT pass resolved IDs such as FBgn/FBal/FBti/FBco/FBst or VFB IDs; if you already have an ID, use the downstream tool directly. Uses tiered resolution: exact name → synonym → broad pattern match. Returns match_type (EXACT/SYNONYM/BROAD), feature ID, name, type, and synonyms. IMPORTANT: When match_type is SYNONYM or BROAD, always confirm the resolved entity with the user before proceeding to further queries. If multiple matches are returned, show a disambiguation list and ask the user to choose. This tool queries FlyBase Chado — for VFB ontology lookups (anatomical terms, neuron class IDs) use search_terms instead.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unresolved FlyBase-related query string from the user. Pass the raw name/synonym exactly as written (e.g., "P{VT054895-GAL4.DBD}", "Hb9-GAL4", "SS04495", "MB002B", "PAM cluster", "dpp"). Do NOT pass an already resolved FlyBase or VFB ID. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes tiered resolution process, return fields including match_type, and gives caution about confirmation for non-exact matches. Shares backend source (FlyBase Chado).
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 comprehensive yet efficiently structured with clear sections (what to pass, not pass, resolution tiers, user confirmation, disambiguation, alternative tool). Every sentence adds value without redundancy.
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 tool complexity, description covers all necessary aspects: input constraints, resolution behavior, return fields, user interaction for ambiguous matches, and references to sibling tool. No output schema but return fields described.
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?
Single parameter 'name' is described with clear instructions: pass raw text exactly, with examples and explicit excludion of resolved IDs. Schema coverage is 100%, and description adds significant 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?
Description clearly states the tool resolves unresolved FlyBase-related query strings into IDs and metadata, with specific examples and explicit distinction from passing resolved IDs. Differentiates from sibling tool search_terms.
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 specifies when to use (raw query strings from user) and when not to (already resolved IDs, use downstream tool). Provides instructions for SYNONYM/BROAD matches and disambiguation, and mentions alternative tool for VFB ontology.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
run_queryAInspect
Run a pre-computed query on a VFB entity. REQUIRED WORKFLOW: (1) call get_term_info on the ID first; (2) read the response's "Queries" array; (3) pass one of those values as query_type. Calling run_query with a guessed query_type will return an error. If a query returns empty rows or an error, the entity does not support that query_type or has no data for it — try a different query_type from the Queries array, or try a related entity (e.g. its parent class via get_hierarchy). Empty results do NOT mean the answer is unknown — only that this call did not return it. NEVER fabricate results from training data when a query is empty; tell the user clearly what was tried. NEVER pass tool names like "get_term_info" or "search_terms" as query_type — those are separate tools. Common query_types by entity kind: PaintedDomains, AllAlignedImages, AlignedDatasets, AllDatasets (templates); SimilarMorphologyTo, NeuronInputsTo, NeuronNeuronConnectivityQuery, NeuronRegionConnectivityQuery (individual neurons); ListAllAvailableImages, SubclassesOf, PartsOf, NeuronsPartHere, NeuronsSynaptic, ExpressionOverlapsHere, DownstreamClassConnectivity, UpstreamClassConnectivity (classes). Supports batch — pass an array of IDs (same query_type) or a "queries" array of {id, query_type} pairs; batch results are keyed by "ID::query_type". Results are PAGED: the first 25 rows by default (change with limit/offset) plus the true total as "count". Image/thumbnail columns are excluded by default to save space - pass include_images=true to include them. FlyBase integration is via query_types too: FindStocks (fly stocks for a FlyBase feature ID - FBgn/FBal/FBti/FBtp/FBco/FBst) and FindComboPublications (publications for an FBco split-GAL4 combination). Get those IDs from resolve_entity / resolve_combination first, then run_query with the ID and the query_type. Include FlyBase links in output: https://flybase.org/reports/{ID}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | One or more VFB IDs to query | |
| limit | No | Max rows returned per call (default 25). The true total is always returned as "count"; broad queries (e.g. ListAllAvailableImages, or NeuronsSynaptic on a whole region) can have thousands to hundreds of thousands of rows. Use 0 for all rows (still capped server-side ~25000 - avoid for broad queries). | |
| offset | No | Row offset for paging (default 0). To get the next page, re-run with offset increased by limit; "count" gives the total. | |
| queries | No | Array of {id, query_type} pairs for mixed batch queries. When provided, id and query_type params are ignored. | |
| query_type | No | A valid query type from the Queries array returned by get_term_info. Used for single id or array of ids. | |
| include_images | No | Include the image/thumbnail column in result rows. Default false: the thumbnail is a long markdown image string that is rarely useful to reason over and greatly inflates every row, so it is stripped and the response says so in _note. Set true to include it (e.g. to build image URLs). |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully covers behavioral traits: paging (limit/offset), image exclusion by default, batch modes, error handling, and FlyBase link inclusion. Discloses that empty results do not mean unknown, and that server caps exist.
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 lengthy but well-structured with clear sections: workflow, error handling, batch, paging, images, FlyBase. Every sentence adds value, though could be slightly more concise 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 no output schema and 6 parameters with nested objects, the description is highly complete. Covers workflow, error handling, batch, paging, images, and provides specific examples. No gaps for an AI agent to infer incorrectly.
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 significant value beyond schema: explains batch modes, paging details, image exclusion rationale, FlyBase query types, and common query_type lists. Provides context that schema alone does not.
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 it runs a pre-computed query on a VFB entity, with a required workflow and examples of query types. It distinguishes from sibling tools like get_term_info and search_terms by specifying that query_type must come from the Queries array.
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 outlines the required workflow: call get_term_info, read Queries array, pass as query_type. Provides guidance on empty results, error handling, and when to try other query_types or entities. Also explains batch usage and FlyBase integration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_termsAInspect
Search VFB terms (Solr). USE filter_types BY DEFAULT — unfiltered searches return deprecated terms, scRNAseq artifacts, and developmental stages mixed in with the entity the user wants.
Common filter_types recipes:
Neuron classes: ["neuron", "class"]
Individual neurons with images: ["neuron", "has_image"]
Neurons with connectome data: ["neuron", "has_neuron_connectivity"]
Brain regions / neuropils: ["anatomy"]
Genes: ["gene"]
Driver lines / expression patterns: ["expression_pattern"]
Datasets: ["dataset"] Add exclude_types: ["deprecated"] to almost any search to remove obsolete entities.
Stage filtering: VFB covers adult, larval, and embryonic data, and many anatomical FBbt classes are stage-agnostic. Do NOT add "adult" or "larva" to filter_types by default — only add them when the user is explicit about a stage (e.g. "adult Kenyon cells", "larval mushroom body"). Default searches should leave stage out so stage-agnostic classes and all life stages are visible.
Useful flags:
minimize_results=true → top 10 + truncation metadata, for exploratory searches.
auto_fetch_term_info=true → if an exact label match is found, returns get_term_info in the same response.
boost_types=["has_image", "has_neuron_connectivity"] → soft-rank data-rich entities first without excluding others.
If the search returns no good matches, do NOT fall back to training-data answers — try alternative spellings, synonyms, broader terms, or different filter_types.
Multiple filter_types are ANDed (results must match ALL). Multiple exclude_types are ORed (any match excludes). boost_types soft-rank without excluding.
Available filter types: entity, anatomy, nervous_system, individual, has_image, adult, cell, neuron, vfb, has_neuron_connectivity, nblast, visual_system, cholinergic, class, secondary_neuron, expression_pattern, gabaergic, expression_pattern_fragment, glutamatergic, feature, sensory_neuron, neuronbridge, deprecated, larva, has_region_connectivity, nblastexp, gene, primary_neuron, flycircuit, mechanosensory_system, histaminergic, lineage_mbp, peptidergic, hasscrnaseq, chemosensory_system, split, has_subclass, olfactory_system, dopaminergic, fafb, l1em, pub, enzyme, motor_neuron, cluster, lineage_6, lineage_3, serotonergic, lineage_19, lineage_cm3, lineage_dm6, proprioceptive_system, gustatory_system, sense_organ, lineage_mbp4, lineage_mbp1, lineage_1, lineage_mbp2, lineage_all1, lineage_balc, lineage_cm4, lineage_dm4, muscle, lineage_13, lineage_8, lineage_mbp3, lineage_12, lineage_dm1, lineage_dpmm1, lineage_9, lineage_cp2, lineage_dl1, fanc, lineage_7, lineage_vpnd2, lineage_dm3, lineage_dpmpm2, lineage_14, lineage_4, lineage_blp1, lineage_dalv2, lineage_eba1, lineage_dm2, lineage_dpmpm1, auditory_system, lineage_16, lineage_blvp1, lineage_blav2, lineage_vlpl2, lineage_alad1, lineage_bamv3, lineage_bld6, lineage_vpnd1, synaptic_neuropil, lineage_23, lineage_17, lineage_10, lineage_dplpv, lineage_21, lineage_alv1
Multiple filter_types are ANDed (results must match ALL). Multiple exclude_types are ORed (any match excludes). boost_types soft-rank matching results higher without excluding others.
| Name | Required | Description | Default |
|---|---|---|---|
| rows | No | Number of results to return (default 150, max 1000) - use smaller numbers for focused searches | |
| query | Yes | Search query (e.g., medulla) | |
| start | No | Pagination start index (default 0) - use to get results beyond the first page | |
| boost_types | No | Boost ranking of results matching these facets_annotation types without excluding others | |
| filter_types | No | Filter results to only include items matching ALL of these facets_annotation types (AND logic) | |
| exclude_types | No | Exclude results matching ANY of these facets_annotation types (OR logic) | |
| minimize_results | No | When true, limit results to top 10 for initial searches and add truncation metadata. For exact matches, return only the matching result. | |
| auto_fetch_term_info | No | When true and an exact label match is found, automatically fetch and include term info in the response. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral details such as AND logic for filter_types, OR logic for exclude_types, soft-ranking for boost_types, and behavior of minimize_results and auto_fetch_term_info. Since no annotations exist, the description fully carries transparency.
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 clear sections for filter recipes, stage filtering, flags, and fallback advice. Every sentence adds value; no fluff despite length.
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?
Thorough for a complex tool with 8 parameters. Covers usage, behavior, and examples. Lacks return format details, but no output schema exists; the description is still highly 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?
Schemas have 100% coverage (baseline 3), but the description adds extensive context: explains filter_types recipes, stage filtering rules, flag usage, and available type values. This far exceeds mere schema documentation.
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 it searches VFB terms via Solr, distinguishes itself by emphasizing the need for filter_types to avoid deprecated/scRNAseq artifacts, and explicitly differentiates from siblings like get_term_info and resolve_entity.
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 guidance: 'USE filter_types BY DEFAULT', when to add stage filters, common filter_type recipes, and fallback strategies. Clearly tells when not to use unfiltered searches.
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!