branchly

get_top_cited_sources

Read-only

Knowledge-base nodes most frequently cited in chat answers, ranked by citation count. Each row carries the node UUID (vertex_id), its title, optional source URL, and citation_count. Use this to understand which knowledge is actually load-bearing; pair with read_node(vertex_id) to inspect cited content.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Maximum number of rows to return, ordered by count descending.
`embed_types`	No	Restrict to sessions initiated through these embed type(s). Omit to include all embeds.
`time_filter`	No	Time window for the analytics query. Accepts either: (a) a preset enum value: 'this_month', 'this_year', 'last_month', 'last_30_days' (default), 'last_6_months', 'last_12_months'; or (b) an explicit ISO date range as 'YYYY-MM-DD,YYYY-MM-DD' (inclusive).	last_30_days

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

TDQS

A4/5.0

Behavior3/5

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

The readOnlyHint annotation already covers safety, and the description adds row-shape details and ranking behavior. It does not disclose edge behavior like empty results or time-filter defaults, but these are minor for a read-only analytics tool and are partly covered by the schema.

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?

Three sentences front-load the core function, then give output fields, then an actionable next step. Every sentence earns its place with no redundant restatement of schema details.

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?

With an output schema, 100% parameter coverage, and a readOnly annotation, the description provides the important missing context: what the rows represent and how to follow up on a vertex_id. It could be slightly sharper about the 'chat answers' scope versus the embed_types options, but it is functionally complete for correct invocation.

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%, and the schema already documents limit, embed_types, and time_filter with defaults and formats. The description adds no parameter-specific detail beyond the schema, so the baseline 3 applies.

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 specific object (knowledge-base nodes), metric (citation count), and ordering (ranked by count), and enumerates the row fields. This clearly differentiates it from sibling tools like get_top_searches or get_top_clicked_urls.

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?

It gives an explicit use case ('understand which knowledge is actually load-bearing') and recommends pairing with read_node(vertex_id) for follow-up. It does not explicitly contrast with all sibling analytics tools, but the context is clear enough for an agent to select it for node-citation analytics.

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?