Skip to main content
Glama

query_connectivity

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. RESULT SIZE: a broad query is enormous (a single class at weight=5 can be over 50,000 connections), so results are ranked strongest-first and paged — you get limit rows (default 50) plus a summary computed over ALL of them: totals, per-dataset counts, distinct neuron counts, and the top class pairs. Answer from the summary and quote a handful of rows; only page with offset if the user asks for specific further rows. 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. group_by_class=true is usually the better first call on a broad query: it rolls the connections up over the subclass hierarchy — a row per (upstream level, downstream level) with data, up to the queried term(s) — instead of returning every neuron pair. Because a connection counts toward every ancestor pair in scope, per-row pairwise_connections and total_weight do NOT sum to the raw connection counts, and a row appears for the queried class itself as well as each subclass with data.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoHow many connection rows to return, strongest first (default 50). The summary always covers every connection found, not just the returned rows. Pass 0 for all rows — only do this on a query you already know is small, as broad queries return tens of thousands.
offsetNoRow to start from within the strongest-first ranking (default 0). Re-running with the same limit and the next offset walks down the list.
weightNoMinimum synapse count threshold (recommended default: 5). Lower to 1 if initial query returns zero results as first relaxation step.
exclude_dbsNoDataset symbols to exclude (recommended default: ["hb", "fafb"] to focus on newer datasets). Pass empty array [] to include all datasets. Must be the exact `symbol` field from list_connectome_datasets — currently BANC, fw, ol, mv, hb, mc, fafb, l1em. An unrecognised symbol is silently ignored by the server rather than reported, so a dataset name ("hemibrain", "male-cns", "flywire") excludes nothing and gives no warning. Call list_connectome_datasets rather than guessing.
upstream_typeNoUpstream (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_classNoIf true, aggregate by class rolled up over the subclass hierarchy: a row appears for the queried class AND each subclass with data (a connection counts toward every ancestor pair up to the queried term(s), so per-row pairwise_connections / total_weight do not sum to the raw counts). Returns total_weight, average_weight, percent_connected and pairwise_connections per class pair, ranked by pairwise_connections. If false (default), returns individual neuron-to-neuron rows.
downstream_typeNoDownstream (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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / group_by_class / description
      Previous value: -"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."New value: +"If true, aggregate by class rolled up over the subclass hierarchy: a row appears for the queried class AND each subclass with data (a connection counts toward every ancestor pair up to the queried term(s), so per-row pairwise_connections / total_weight do not sum to the raw counts). Returns total_weight, average_weight, percent_connected and pairwise_connections per class pair, ranked by pairwise_connections. If false (default), returns individual neuron-to-neuron rows."
  2. Changed3 schema fields changed
    • changedInput schema / properties / exclude_dbs / description
      Previous value: -"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."New value: +"Dataset symbols to exclude (recommended default: [\"hb\", \"fafb\"] to focus on newer datasets). Pass empty array [] to include all datasets. Must be the exact `symbol` field from list_connectome_datasets — currently BANC, fw, ol, mv, hb, mc, fafb, l1em. An unrecognised symbol is silently ignored by the server rather than reported, so a dataset name (\"hemibrain\", \"male-cns\", \"flywire\") excludes nothing and gives no warning. Call list_connectome_datasets rather than guessing."
    • addedInput schema / properties / limit
      Added value: +{
      +  "default": 50,
      +  "description": "How many connection rows to return, strongest first (default 50). The summary always covers every connection found, not just the returned rows. Pass 0 for all rows — only do this on a query you already know is small, as broad queries return tens of thousands.",
      +  "type": "number"
      +}
    • addedInput schema / properties / offset
      Added value: +{
      +  "default": 0,
      +  "description": "Row to start from within the strongest-first ranking (default 0). Re-running with the same limit and the next offset walks down the list.",
      +  "type": "number"
      +}
  3. Added

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description carries the full behavioral burden, and it does so thoroughly. It discloses live-query latency, enormous result sizes, strongest-first ranking and paging, summary semantics, silent ignoring of unrecognized exclude_dbs symbols, and the non-additive behavior of group_by_class. This gives an agent accurate expectations before invoking.

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 long but densely informative and organized with clear labels (CONSTRAINTS, RECOMMENDED DEFAULTS, RESULT SIZE, WORKFLOW). It repeats a few points already present in the schema, such as recommended defaults and anatomical-region restrictions, but given the tool's complexity and failure modes, the length is mostly justified and critical warnings are front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description covers return shape, summary fields, ranking, paging discipline, group_by_class semantics, user-confirmation workflow, validation, and result-relaxation strategies. It also clarifies how an agent should answer from the summary rather than blindly paging. For a 7-parameter live-query tool with no annotations, nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds substantial meaning beyond the schema: recommended defaults, OWL ID/label requirements, the need to validate labels via search_terms, exact dataset symbols and the silent-ignore pitfall, limit behavior with 0, and step-by-step relaxation guidance. These additions materially improve parameter selection.

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 states a precise verb, resource, and scope: 'Query synaptic connectivity between Drosophila neuron classes across ALL connectome datasets simultaneously.' It also differentiates this tool from siblings by warning 'This is NOT pre-cached' and explicitly pointing to run_query for individual neuron-neuron connections, so an agent can select it correctly without guessing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is explicitly specified: at least one of upstream_type/downstream_type is required, both should be set for a directed pair query, anatomical regions are invalid, and individual-neuron queries should go to run_query. It also gives a concrete workflow: confirm parameters, canonicalize labels with search_terms, apply recommended defaults, and follow a relaxation sequence when zero results appear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.