branchly

list_nodes

Read-only

List nodes in the knowledge base. Optionally filter by vertex label(s), data source type(s), or data source IDs. Optionally sort by updated_at ('asc' or 'desc'). Provide 'query' and 'locale' to perform a full-text search across node content (requires both parameters). Returns paginated results with total count.

Input Schema

TableJSON Schema

Name	Required	Description
`page`	No
`limit`	No
`query`	No	Full-text search query across node content. When provided, 'locale' must also be provided. Leave empty to list without search.
`labels`	No	Filter by vertex label(s) (e.g. 'content'). Returns all when omitted.
`locale`	No	Valid Locale configured in the application for full-text search (e.g. 'de', 'en'). Required when 'query' is provided. Ignored otherwise.
`data_source_ids`	No	Filter by data source UUID(s). Returns all when omitted.
`sort_parameters`	No	Sort order, e.g. [{"field": "updated_at", "direction": "desc"}].
`data_source_types`	No	Filter by data source type(s): 'website_crawler', 'pdf_upload', 'open_api', 'helpspace', 'custom_webcrawler', 'webhook'. Returns all when omitted.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is clear. The description adds value beyond annotations by explicitly stating that 'query' and 'locale' must both be provided for full-text search and that results are paginated with a total count.

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 three focused sentences: it states the core purpose, lists the available optional behaviors, and notes the search precondition and pagination. Every sentence contributes distinct information without redundancy or filler.

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?

For an 8-parameter optional-filter list tool with a rich input schema and an output schema, the description sufficiently covers the key invocation details: filters, sorting, search requirements, and pagination. An agent has enough context to call this tool correctly without needing the description to repeat schema or return-format details.

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 75%, so most parameters are already documented with defaults, enums, and conditions. The description reiterates the query/locale coupling and mentions filter dimensions, but it does not add substantial semantic meaning beyond what the input 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 starts with 'List nodes in the knowledge base,' clearly identifying the verb and resource. It further specifies optional filtering by labels, data source types/IDs, sorting, and full-text search, which distinguishes it from sibling tools like read_node and list_data_sources.

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

Usage Guidelines4/5

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

The description gives clear context for when to use the tool: listing nodes with optional filters, sorting, and paginated full-text search. It does not explicitly name alternatives or state when not to use this tool, but the usage context is unambiguous enough for an agent to select it correctly.

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

All branchly tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.7/5.0

Disambiguation5/5

Each tool targets a distinct resource or metric. The many get_top_* endpoints are differentiated by the specific dimension measured, and read_* / list_* / get_* verbs consistently separate detail retrieval from aggregation and paginated listings. Explicit distinctions like get_top_languages vs get_top_locales and get_top_interaction_sources vs get_top_clicked_urls remove ambiguity.

Naming Consistency5/5

Tool names follow a predictable verb_noun pattern: create_* for mutations that add, update_* for edits, list_* for paginated collections, read_* for detailed record access, and get_* for aggregate analytics. Even with 33 tools the naming convention is uniform and readable.

Tool Count2/5

33 tools exceeds the 25+ threshold for 'too many' and is heavy for a single server surface. While the analytics getters are individually focused, the set is larger than typical for an MCP server and could be consolidated or grouped more tightly.

Completeness3/5

Analytics coverage is thorough, and nodes/prompts have create/read/update lifecycles. However, there are no delete operations anywhere, and data sources and tools support update but not create or delete, leaving notable lifecycle gaps for administrative tasks.

Resources

Need Help?