Skip to main content
Glama
dagistankaradeniz

quillink-mcp

get_graph_analysis

Detect communities and rank important nodes across your entire Quillink account graph using Louvain, label propagation, PageRank, or other selectable algorithms.

Instructions

Community detection + importance ranking over the caller's whole account graph. community_algo: "louvain" (default), "label_propagation", "greedy_modularity", or "connected_components". centrality_algo: "pagerank" (default), "betweenness", "degree", or "closeness". Requires a Pro plan, same gate as get_global_note_graph. On a very large graph the response may note that a cheaper approximation was substituted for the exact algorithm requested.

Input Schema

NameRequiredDescriptionDefault
community_algoNolouvain
centrality_algoNopagerank

Output Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the Pro-plan gate and the notable behavior that 'on a very large graph the response may note that a cheaper approximation was substituted'. It does not mention latency, rate limits, or cost of the expensive algorithms, which are the remaining meaningful behavioral gaps.

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?

Front-loaded with purpose, then parameters, then gating, then the approximation caveat — a logical ordering with no filler sentences. It is dense and slightly run-on, but every clause carries distinct information.

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?

For a 2-parameter tool with an output schema (so return values need no explanation) and no annotations, the description covers purpose, algorithm options, plan gating, and the approximation caveat. The missing piece is explicit differentiation from the sibling graph tools.

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?

Schema description coverage is 0% and neither parameter declares an enum, but the description enumerates every accepted value for community_algo and centrality_algo and marks the defaults. This fully compensates for the schema gap, leaving only minor omissions such as value-specific tradeoffs.

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?

States a specific verb+resource: 'Community detection + importance ranking over the caller's whole account graph'. The scope phrase 'whole account graph' implicitly separates it from note-level graph siblings like get_note_graph, though the distinction is never made explicit. An agent can tell what it does but must infer why it differs from the other graph tools.

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 names a prerequisite ('Requires a Pro plan, same gate as get_global_note_graph') and lists algorithm choices, which hints at when the tool is applicable. However it never says when to prefer this over get_note_graph, get_global_note_graph, or get_related_notes, nor when-not to use it. Usage is implied rather than stated.

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