NetworkX MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v3.1.0
Disambiguation2/5
Multiple tools have overlapping purposes (degree_centrality, betweenness_centrality, and centrality_measures all compute centrality metrics). The inclusion of unrelated domains (citation analysis, CI/CD workflows) alongside graph operations creates significant confusion about tool selection for an agent.
Naming Consistency4/5
Most tools follow a clear verb_noun snake_case pattern (create_graph, add_edges, delete_graph, trigger_workflow), but a few deviate (pagerank, subgraph, matching, topological_sort). Overall the convention is consistent and readable.
Tool Count1/5
With 46 tools spanning three very different domains (NetworkX graphs, citation networks, CI/CD workflows), the server is excessively large and unfocused. Each domain individually would warrant a smaller, dedicated tool set; combining them makes the count inappropriate.
Completeness2/5
The graph operations lack obvious essentials such as listing edges or updating graph structure. The citation and CI/CD domains appear arbitrarily bolted on, and while each has some coverage, the overall surface is incomplete for any single coherent purpose.
Average 2.8/5 across 46 of 46 tools scored. Lowest: 1.3/5.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 21 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 28, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that the tool gets information, implying a read operation, but fails to disclose potential errors, data format, or any side effects. The description is insufficient to understand the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short, but not because it is appropriately concise—it is under-specified. The single sentence 'Get graph information' conveys minimal information and lacks front-loaded details that would help an agent decide whether to invoke the tool. It does not earn its place as a useful description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and any parameter documentation, the description is completely inadequate for a tool with a required 'graph' parameter. It does not explain what information is retrieved, error conditions, or relationship to sibling tools, making it impossible to use correctly without external knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines a single 'graph' parameter of type string, but schema description coverage is 0%. The description does not explain what the 'graph' parameter refers to (e.g., graph name, ID) or how it should be formatted. The phrase 'graph information' does not clarify the parameter's purpose or expected values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get graph information' with a clear verb, but the resource is vague ('graph information') and does not distinguish this tool from siblings like graph_statistics or get_node_attributes. It implies a read operation on a graph but lacks specificity about what kind of information is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description provides no context for choosing 'get_info' over sibling tools such as graph_statistics or get_node_attributes, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention what the visualization output looks like, whether an existing graph is required, or any effects on the graph data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but underspecified. It lacks sufficient detail to be useful, making it under-specification rather than genuine conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the presence of two parameters, the description is inadequate. It does not explain return values, prerequisites, or how this tool relates to the many sibling graph tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'graph' only as a generic noun and completely omits the 'layout' parameter, adding no value beyond the schema's raw field names.
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?
The description clearly states the tool creates a visualization of a graph, using a specific verb and resource. It is the only visualization tool among siblings, so it stands out, but it lacks specificity about the kind of visualization or output format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus alternatives. The description simply states the action without any context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention whether the tool is read-only, what output to expect, whether it modifies the graph, or any prerequisites. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words, which is positive. However, it is under-specified to the point of being minimally viable; it could be expanded without losing conciseness to add necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations, output schema, and parameter descriptions, the description is severely incomplete. It fails to define what 'collaboration patterns' means, what the output represents, or how the graph parameter should be passed, making the tool hard to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description does not explain the meaning or expected format of the required 'graph' parameter. It neither confirms that 'graph' refers to the citation network nor provides examples or constraints, so the agent has no semantic guidance beyond the parameter name.
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?
The description uses a specific verb ('Find') and resource ('collaboration patterns in citation network'), clearly indicating the tool's function. However, it does not differentiate this tool from siblings like community_detection or graph_statistics, which could overlap in purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description only states what it does, not the context or conditions under which it should be chosen, lacking any exclusions or alternative recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the behavioral burden. It implies a mutation (adding edges) but discloses nothing about side effects, return values, idempotency, or edge cases (e.g., duplicate edges, non-existent graph). This is inadequate for a write operation, but not actively misleading.
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 a single short sentence with no wasted words; it is concise and front-loaded. However, it is under-specified, lacking necessary context for a useful tool description. It earns its place but does not utilize the opportunity to add value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and minimal parameter coverage, the description is far from complete. It doesn't explain how the tool behaves, what the return value is, or how to correctly construct the edge list. A simple tool still needs more context to be reliably used by an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description offers zero explanation of the parameters. It doesn't clarify what the 'edges' array should contain (e.g., pairs of nodes) or the format of the 'graph' parameter. The schema provides only structural types without semantic meaning, and the description fails to compensate.
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?
The description states a clear action and target: 'Add edges to a graph'. It distinguishes the tool from siblings like add_nodes and remove_edges by naming the specific operation and resource. However, it doesn't specify the format or structure of edges, relying entirely on the schema for that information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or context. It is a single declarative sentence with no mention of use cases, required graph existence, or interaction with other graph operations. There is no explicit when or when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action ('Add nodes') and does not disclose whether nodes are overwritten, whether the graph must exist, or any side effects. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with no filler words, which is concise in wording. However, it is under-specified and lacks necessary details, so the conciseness comes at the expense of completeness. The structure is minimal but acceptable for the simplicity of the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is too sparse to guide correct usage. It leaves out critical context about graph existence requirements, duplicate handling, and error cases. Given the complexity of the graph domain and many sibling tools, this description is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% and the description adds no meaning beyond the parameter names. It does not clarify what the 'graph' parameter should contain (ID vs name) or what format 'nodes' should follow. The description fails to compensate for the lack of schema descriptions.
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?
The description uses the specific verb 'Add' and identifies the resource 'nodes' and target 'graph', making the primary action clear. However, it does not distinguish this tool from closely related siblings like add_edges or remove_nodes, so it's clear but not fully differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites such as the graph already existing, nor does it explain what happens if nodes already exist. There is no context to help an agent decide between this and add_edges or create_graph.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior, but it only says 'analyze workflow failures with AI-powered insights'. It does not mention whether the operation is read-only, what data it accesses, or what kind of insights are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise, but it sacrifices necessary information. The phrase 'AI-powered insights' adds little concrete value and could be omitted without loss.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has minimal context: no annotations, no output schema, and a single parameter. Yet the description does not clarify what constitutes a 'failure', what insights are produced, or how this relates to sibling workflow tools. It leaves too much unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, run_id, with no description. The tool description provides no explanation of what run_id refers to or how it influences the analysis, and schema description coverage is 0%.
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?
The description clearly identifies the resource and action: 'Analyze workflow failures' with 'AI-powered insights'. It appears distinct from sibling tools like get_workflow_status and rerun_failed_jobs, though the exact nature of 'AI-powered insights' is vague.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool vs alternatives, such as rerun_failed_jobs or get_workflow_status. The description only states what it does, not when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It mentions the CrossRef API hinting at external network calls, but does not disclose rate limits, failure modes, whether the graph must pre-exist, or if the tool modifies the graph in place. Significant behavioral context is missing.
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 a single, concise sentence with no wasted words. It is front-loaded with the main action and source, making it easy to parse, though the extreme brevity contributes to the lack of semantic depth.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API, graph mutation, multiple parameters), the description is severely incomplete. It lacks parameter details, behavioral expectations, and usage context, making it inadequate for an agent to invoke correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the parameters. The phrase 'from DOIs' hints at seed_dois, but the 'graph' and 'max_depth' parameters are entirely unexplained, leaving the agent without necessary semantics.
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?
The description clearly states a specific action ('Build citation network') and its source ('from DOIs using CrossRef API'), making it distinguishable from generic graph operations. However, it doesn't explicitly name sibling alternatives, so it falls short of a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like create_graph or add_nodes. The description does not mention prerequisites, exclusions, or recommended scenarios, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. It implies a read-only calculation but does not state that explicitly, nor does it mention whether the tool modifies the graph, handles weighted graphs, or has limitations. No return format or side effects are described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, which is efficient and front-loaded with the core purpose. However, it lacks important details, making it more under-specified than appropriately concise. A longer but more informative description would earn a higher score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema (one parameter) and lack of annotations/output schema, the description needs to compensate by explaining input and output expectations. It only states the high-level operation, leaving the agent uninformed about the graph parameter format and the structure of the returned centrality values. This is insufficient for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'graph' parameter at all. It gives no hint about the expected format (e.g., graph ID, JSON, or object reference), leaving the agent completely uncertain about how to invoke the tool.
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?
The description clearly states the tool's purpose: calculating degree centrality for all nodes. It uses a specific verb ('calculate') and a specific metric ('degree centrality'), distinguishing it from sibling tools like pagerank or betweenness_centrality, though it does not explicitly differentiate from centrality_measures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use degree_centrality versus alternatives such as pagerank, betweenness_centrality, or centrality_measures. The description does not explain the context or prerequisites for using this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only says 'detect research trends over time,' which hints at an analysis/read operation but does not state whether the graph is modified, what return value is produced, or what constraints exist (e.g., time_window units, required graph structure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler, making it easy to read. However, it is underspecified: it provides only a purpose clause and omits all practical information, so the brevity is a liability rather than a strength.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, no annotations, and sibling tools performing related analyses, a one-line description is far from complete. The agent cannot infer return values, parameter semantics, or appropriate usage context, leaving the tool inadequately specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema includes 'graph' and 'time_window', but the description offers no explanation of either parameter. With 0% schema description coverage, the description was expected to clarify that 'graph' is the network to analyze and what 'time_window' means, but it does not.
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?
The description clearly states the tool's purpose with a specific verb ('detect') and object ('research trends') over time. However, it does not distinguish this tool from sibling tools like 'analyze_author_impact' or 'graph_statistics' in terms of method or scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as 'find_collaboration_patterns' or 'build_citation_network'. The description only implies it is for trend detection, with no exclusions, prerequisites, or context for selecting it over siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only says 'Get all neighbors' without explaining whether this includes incoming/outgoing edges, output format, error handling for missing nodes or graphs, or whether the result is ordered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single-sentence description is concise and front-loaded, but it is under-specified and omits essential behavioral context, making it less useful than an appropriately sized description that includes trade-offs or edge cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get operation, the description is too sparse. It does not cover return value, default behavior, or error conditions, making it incomplete for an agent to invoke correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond param names. It never explains the 'graph' parameter or what values are expected for 'node', leaving the agent to infer semantics solely from the identifier names.
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?
The description clearly states the action ('Get') and the resource ('neighbors of a node'), making the tool's purpose specific and distinguishable from sibling graph algorithms. It lacks nuance about directed vs. undirected graphs, but the core purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like degree_centrality or connected_components. There is no mention of directed graph behavior, preconditions (e.g., node existence), or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the operation ('calculate maximum flow') and the graph type ('directed graph'), but does not disclose return value, whether it mutates the graph, assumed graph representation, error conditions, or capacity conventions. This is a significant transparency gap for a computational algorithm.
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 a single concise sentence with no unnecessary words, making it front-loaded and easy to parse. However, it is arguably too terse, sacrificing critical detail for brevity, but the conciseness itself is not padded or redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex (network flow algorithm) with 4 parameters, no output schema, and no annotations. The description only provides the core verb and resource, omitting graph representation, capacity handling, return format, and any usage constraints. This is far from complete for an agent to invoke the tool correctly without additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description provides no explanation of the parameters. The schema lists graph, source, sink, and capacity, but the description does not clarify what 'graph' format is expected, what source/sink refer to, or that capacity names an edge attribute. The description adds no value to understanding the parameters.
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?
The description uses a specific verb 'Calculate' and identifies the resource 'maximum flow', clearly distinguishing it from sibling graph algorithms like shortest_path. However, it could be more precise by mentioning 'from source to sink' and the dependency on edge capacities, which the schema implies but the description omits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage context is provided. The description does not explain when to choose max flow over other algorithms, what prerequisites exist (e.g., directed graph with capacities), or mention any alternatives. The usage is only implied by the tool's name and the verb 'calculate', leaving the agent without explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavioral traits, but it only states the algorithm name. It does not mention whether the graph is modified, whether it works only on undirected graphs, what the return value looks like, or any side effects. This leaves the agent without critical behavioral context.
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 a single, concise sentence that puts the main action first. It avoids redundant wording and is easily scannable. However, it is somewhat under-specified, but conciseness measures efficient use of words, which is well done.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides only the basic purpose and algorithm name. There is no output schema, so the description should explain the return value (e.g., community assignments). It also does not describe any constraints like graph requirements or parameter formatting. Given the tool's complexity and lack of structured metadata, the description is incomplete for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'graph' (string) with 0% schema description coverage. The description does not clarify what the 'graph' parameter expects (e.g., graph ID, name, or object). It only says 'in the graph' without adding any meaning about how to specify the graph, failing to compensate for the schema's lack of documentation.
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 clearly states the tool's function: 'Detect communities in the graph using Louvain method'. It uses a specific verb ('detect') with a specific resource ('communities in the graph') and distinguishes itself from sibling tools like connected_components or clustering_coefficients by naming the Louvain algorithm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention alternative graph algorithms or any conditions, prerequisites, or exclusions. The only implied usage is that it is for community detection, but no explicit when-to-use/when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description discloses no behavioral traits beyond the action itself. It does not state whether the operation is read-only, what it returns, or any side effects, leaving the full burden unmet.
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 a single concise sentence with no wasted words and the main verb is front-loaded. While it is under-specified, it is well-structured and efficient for the information it does convey.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must explain return value and usage context. It fails to specify what the output is or how the 'graph' parameter should be provided, leaving significant ambiguity despite the simple parameter set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes a single 'graph' string parameter with 0% coverage in the description. The description does not explain the expected format, meaning, or how to reference the graph, failing to compensate for the lack of schema details.
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 uses a specific verb 'find' and resource 'connected components', clearly stating the operation. It distinguishes from sibling graph algorithms like pagerank, shortest_path, and community_detection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or when connected_components is preferable to similar graph analysis tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the algorithm but doesn't disclose whether the graph is mutated, what the output format is, or any side effects. For a graph algorithm tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately brief at one sentence, but it is under-specified. It lacks structure or any breakdown of parameters. It earns its place only by stating the core purpose, but could be improved with minimal additions like strategy options or output description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (graph algorithm), lack of annotations, output schema, and 0% schema coverage, the description is severely incomplete. It doesn't explain return values, side effects, or parameter semantics, leaving the agent without enough information to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the parameters. The 'strategy' parameter is not explained (e.g., what values like 'largest_first' mean), and the 'graph' format (string) is ambiguous. The description does nothing to compensate for the missing schema documentation.
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 clearly states the action ('Color graph vertices') and specifies the method ('using greedy algorithm'), making it distinct from sibling graph tools like shortest_path or pagerank. It uses a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention any prerequisites, use cases, or situations where graph coloring is appropriate or not. Sibling tools like community_detection could be alternatives, but no distinction is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only restates the concept of the tool; it doesn't disclose output format, behavior on disconnected graphs, edge cases, or side effects (though likely read-only).
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 a single concise sentence with no redundant wording. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters and no output schema, yet the description only states the high-level goal. It omits critical operational details: what format the graph parameter expects, how weight is specified, how algorithm choice affects results, and what the return value contains.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description provides zero parameter information. The meaning of 'graph' (string), 'weight' (string), and 'algorithm' choices is left entirely to the schema, which itself has no descriptions.
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?
The description clearly states the tool's function: 'Find minimum spanning tree of an undirected graph'. It identifies the operation (find MST) and the input scope (undirected graph). While it doesn't explicitly distinguish from sibling graph algorithm tools, the MST concept is inherently distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool over alternatives like shortest_path or connected_components. No prerequisites, algorithm selection (Kruskal vs Prim), or when to choose this tool are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It does not reveal whether removing nodes also removes associated edges, whether the operation is reversible, or any side effects. This is a significant gap for a mutation tool on a graph structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concisely complete. It lacks essential context such as behavior on edges, return value, or parameter semantics, so its brevity is a deficiency rather than an asset.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a basic graph mutation tool with no annotations and no output schema, so the description must explain the operation's effects and context. It fails to address what happens to connected edges, how the graph is referenced, or what the tool returns, leaving the agent with insufficient information to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only repeats the name 'nodes' without explaining what the 'graph' parameter refers to (ID, name, object?) or what format the 'nodes' array should take (strings, numbers, IDs). The description adds no value beyond the schema's type definitions.
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 'Remove nodes from a graph' uses a specific verb ('Remove') and clearly identifies the resource ('nodes') and the target ('a graph'). It distinguishes itself from sibling tools like remove_edges and add_nodes, making the tool's purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives (e.g., remove_edges or delete_graph). It does not mention any prerequisites, typical use cases, or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral transparency burden. It only states the calculation and gives no details about side effects, input requirements, return format, or exceptions. This is minimal disclosure and insufficient for a full understanding of the tool's behavior.
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 a single, concise sentence that directly states the tool's purpose without unnecessary words. Every word earns its place, and the structure is highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no annotations, and no output schema, the description must provide more context. It only states the basic calculation, omitting details about input format, return values, and usage scenarios. This makes it incomplete for an agent to confidently invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter 'graph' with no description (0% coverage), and the tool description does not explain what this parameter should contain (e.g., graph name, graph object). The description adds no meaning beyond the parameter name, leaving the agent without necessary input context.
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?
The description uses a specific verb 'Calculate' and identifies the resource 'clustering coefficients for all nodes,' making the tool's purpose clear. However, it does not differentiate this tool from sibling centrality metrics like degree_centrality or betweenness_centrality, so it lacks the explicit sibling distinction that would earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives. The description simply states what it does, with no mention of use cases, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only states the action without explaining consequences, such as what happens if the graph already exists, whether it overwrites, or what the return value is. It provides minimal transparency beyond the fact that a graph is created.
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 a single, concise sentence with no superfluous words. It states the action directly and efficiently, earning a perfect score for conciseness and structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with only two parameters, but the description is extremely sparse. It omits crucial details like error behavior, idempotency, and return values, especially since there is no output schema. The lack of any annotation further reduces context, making the description incomplete for an agent to understand full implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0%, meaning no parameter descriptions are provided, and the description does not compensate. 'Create a new graph' does not explain the 'name' or 'directed' parameters, leaving the agent to infer their meaning from names alone. This is insufficient given the lack of schema descriptions.
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?
The description 'Create a new graph' clearly states the tool's function with a specific verb and resource. It distinguishes itself from sibling tools like add_nodes and delete_graph, though it doesn't elaborate on what constitutes a graph or provide any extra context beyond the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as list_graphs or import_csv. The description lacks any context for when creating a graph is appropriate, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure, but it only says 'Get'. It does not mention whether the operation is read-only, what happens if the edge is missing, error behavior, or performance implications. This is a significant gap.
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 a single concise sentence that is front-loaded and gets to the point. It is not overly verbose, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given three required parameters, no annotations, and no output schema, the description is incomplete. An agent would not know what the return value looks like, how to handle non-existent edges, or any important caveats. The description is too sparse for reliable tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain the parameters. However, it only names the edge concept without elaborating that source and target identify the edge, or what types/formats are expected. The description adds almost no meaning beyond the raw schema.
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?
The description clearly states the tool retrieves all attributes of an edge, using the verb 'Get' and resource 'attributes of an edge'. This distinguishes it from sibling tools like set_edge_attributes or get_node_attributes, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, no prerequisites, and no context about typical use cases. It simply states the function without any decision-making support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the calculation but does not describe whether the graph is modified, what the return value looks like, or any side effects. 'Calculate' implies a read-only operation, but this is not explicit.
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 a single concise sentence that is front-loaded with the action and resource. It contains no wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an algorithm tool with no annotations and no output schema, this description is too sparse. It does not mention return values, input requirements, or anything about how the graph should be supplied, making it barely adequate for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no information about the 'graph' parameter, such as expected format, whether it is an ID or an object, or how it should be provided. The parameter name alone is not enough.
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?
The description uses a specific verb ('Calculate') and resource ('PageRank for all nodes'), clearly stating what the tool does. It does not explicitly distinguish itself from sibling centrality measures, but the algorithm name itself provides sufficient specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like degree_centrality or betweenness_centrality. It also does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions 'citation network analysis' but does not explain how recommendations are generated, whether the tool modifies state, what kind of graph is expected, or what the response contains. This is a significant gap.
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 a single concise sentence with no filler or repetition. However, it is under-specified rather than truly concise; while the structure is clean, the missing details prevent it from being excellent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are three parameters, no output schema, and no annotations, the description is inadequate for an agent to correctly invoke the tool. It does not explain the required graph format, how seed_doi is used, or what the return value looks like, making the description incomplete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage, and the description does not define parameters such as graph, seed_doi, or max_recommendations. The phrase 'citation network analysis' weakly implies that graph is a citation network and seed_doi is a starting point, but this is far from explicit and offers little value beyond what the parameter names suggest.
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?
The description clearly states the tool recommends papers using citation network analysis, which is a specific verb and resource. It stands apart from sibling tools like pagerank or analyze_author_impact by naming the 'recommend' action, though it does not explicitly contrast itself with those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as build_citation_network or analyze_author_impact. There are no stated prerequisites, expected inputs, or exclusions, leaving the agent to infer usage context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavior such as return value, side effects, or whether the graph is modified. The description only states the operation without any additional context.
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 single-sentence description is concise and free of redundant wording. However, it is so terse that it omits important details, though not to the point of being a mere tautology.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a graph algorithm with no output schema, no annotations, and three parameters at 0% schema coverage, the description is inadequate. It does not specify the input graph format, output structure, or algorithmic limitations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description does not explain the parameters. 'Graph' is ambiguous (could be an ID or an inline object), while source/target are only self-evident by name. The description adds no value beyond the schema field names.
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?
The description 'Find shortest path between nodes' uses a specific verb and resource, clearly conveying the tool's purpose. It distinguishes from siblings like pagerank or connected_components, though it does not explicitly mention the graph dependency.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. It does not mention prerequisites, nor does it compare with sibling tools like minimum_spanning_tree, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It only says 'Trigger', implying a mutating action, but fails to disclose side effects (e.g., creating a new run, consuming minutes), authentication requirements, or whether the operation is asynchronous. No contradiction exists, but the information is insufficient.
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 a single, focused sentence with no filler words, making it highly concise. However, it is arguably too terse for a mutating tool with parameters, but structurally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and leaves many important aspects unaddressed: no return value, no side effects, no prerequisites, and no relationship to sibling workflow tools. Given the lack of annotations and output schema, this is inadequate for a tool that triggers external processes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for 'workflow' and 'inputs' (67% coverage), but the tool description adds no explanation of parameter usage, such as how to construct the JSON inputs or the meaning of branch's default. It does not compensate for the missing 'branch' description.
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?
The description uses the specific verb 'trigger' with the resource 'GitHub Actions workflow', clearly indicating the action. It distinguishes from sibling tools like get_workflow_status and cancel_workflow by the action verb, but does not explicitly name alternatives or scope details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_workflow_status, cancel_workflow, or rerun_failed_jobs. It does not state prerequisites (e.g., workflow file must exist) or context like 'manually dispatch a workflow run'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It indicates destruction via 'Delete' but does not state whether deletion is permanent, reversible, or fails on nonexistent graphs. No return behavior is described.
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 a single, front-loaded sentence with no filler. It is concise, though it sacrifices necessary detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter delete tool with no annotations and no output schema, the description is too sparse. It omits behavior on errors, return values, and parameter semantics, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the 'graph' parameter. The parameter name is a bare string with no explanation of expected format (ID, name, path), making it ambiguous for the agent.
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 'Delete a graph from storage' uses a specific verb and resource, clearly distinguishing it from sibling tools like create_graph, list_graphs, and import_csv. It unambiguously states the tool's action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives, no prerequisites mentioned, and no exclusions. The description only states what it does, not contextual use cases or caveats.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. It merely restates the operation ('Get all attributes') without specifying return format, error handling, whether attributes include system-defined ones, or any side effects. The phrase 'all attributes' is ambiguous and could lead an agent to misunderstand the output.
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 a single concise sentence with no extraneous words. It effectively front-loads the core action and is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter getter with no output schema and no annotations, the description is too sparse. It does not explain what 'attributes' means, what the return value looks like, or what happens if the node does not exist. An agent could invoke it but would lack crucial information to interpret the result correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It clarifies that the 'node' parameter refers to a node whose attributes are retrieved, but it does not explain that 'graph' identifies the graph containing the node, nor does it describe expected value formats beyond the schema. The description adds minimal value over the self-explanatory parameter names.
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?
The description clearly states the tool retrieves all attributes for a node using a specific verb ('Get') and resource ('attributes of a node'). It is specific and unambiguous, though it does not explicitly distinguish itself from sibling tools like get_edge_attributes or set_node_attributes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as get_edge_attributes, get_neighbors, or set_node_attributes. There is no mention of prerequisites, typical use cases, or what distinguishes this operation from similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states 'find', implying a read operation, but does not mention whether the graph is modified, what output format to expect, or any constraints on the input graph. This is insufficient for a tool without structured safety metadata.
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 a single, front-loaded sentence with no wasted words. While it is concise, it omits critical details that would be expected given the tool's complexity, but conciseness itself is strong.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a graph algorithm tool with two parameters, no output schema, and no annotations. The description only names the algorithm, leaving out input format, return value, and any behavioral details. Given the complexity of maximum weight matching, the description is severely incomplete for an AI agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either 'graph' or 'max_cardinality'. It fails to explain what format 'graph' should take (e.g., adjacency list, edge list) or what 'max_cardinality' controls. The tool provides no semantic value for the parameters beyond their names.
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 'Find maximum weight matching in a graph' uses a specific verb and resource, clearly identifying the tool's purpose. It distinguishes itself from sibling graph algorithms like shortest_path and minimum_spanning_tree by naming a specific type of matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., weighted graph) or exclusions, leaving the agent to infer usage purely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely restates the tool name. It does not disclose side effects, idempotency, whether a new run is created, permissions required, or any destructive impact, which is critical for a tool that reruns jobs.
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 a single short sentence that is front-loaded and to the point. It is concise, but the brevity comes at the cost of necessary behavioral and usage details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations, output schema, and parameter explanation, the description is inadequate for understanding the full context of the operation. It does not explain what happens to the workflow, whether jobs are retried individually, or what the expected outcome is.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the run_id parameter at all. The parameter's purpose, format, and how to obtain it are left entirely to inference from its name.
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 uses a specific verb ('rerun') with a specific resource ('failed jobs') scoped to a workflow. This clearly distinguishes it from sibling tools like trigger_workflow, get_workflow_status, and cancel_workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, when a rerun is appropriate, or when to prefer other workflow management tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It does not state that the operation is read-only, whether it has side effects, or what happens if the graph or author is missing. The description is silent on permissions and output behavior.
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 a single concise sentence that is front-loaded with the primary action. It contains no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too minimal for a tool with no annotations, no output schema, and 0% schema coverage. It does not explain what impact metrics are included, what the output format is, or what kind of graph is expected. This is inadequate for an agent to reliably invoke the tool.
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 coverage is 0%, so the description must illuminate the parameters. 'Analyze author impact metrics' implies author_name refers to the researcher and graph refers to the underlying dataset, but it does not explain what the graph should represent or the expected values. Some semantic value is added over bare schemas, but it's insufficient.
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?
The description 'Analyze author impact metrics including h-index' clearly states the tool's purpose with a specific verb and resource. It distinguishes itself from sibling graph analysis tools by focusing on author-specific bibliometric metrics like h-index, but does not explicitly mention context like citation networks, so it's not fully distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No mention of prerequisites (e.g., graph must be a citation network) or exclusions. The description only states what it does, not when to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Calculate' implies a read-only operation, but it does not mention computational cost, graph requirements, or what the result looks like. It offers no behavioral context beyond the action itself.
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 a single focused sentence with no filler, making it concise and front-loaded. It states the action and target clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having only one parameter and no output schema, the description omits the meaning of the graph parameter and the return format. This makes it under-specified for an agent to select and use confidently in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not explain what 'graph' refers to (e.g., graph ID or structure). The single parameter is left ambiguous, so the agent cannot reliably invoke the tool without additional knowledge.
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 uses a specific verb 'Calculate' and identifies the resource 'betweenness centrality' with scope 'for all nodes', clearly distinguishing it from sibling tools like pagerank or degree_centrality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool over alternatives such as degree_centrality or centrality_measures. The description implies usage but does not state context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It simply states 'Cancel a running workflow' but does not reveal whether the cancellation is destructive, irreversible, whether it loses progress, or if it is synchronous. This is a significant gap for a cancellation operation.
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 an ultra-short single sentence, front-loaded with the verb. It wastes no words and is appropriately sized for a simple tool, though it sacrifices clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one parameter, no annotations, and no output schema. The description does not explain return values, post-cancellation behavior, or how to verify the cancellation (e.g., via get_workflow_status). Given the tool's simplicity, the description is minimally adequate but lacks important contextual details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, run_id, but the description provides zero parameter information (schema description coverage is 0%). The description does not explain what run_id represents or how to obtain it, despite the parameter name being somewhat self-explanatory. The description should at least hint that run_id identifies the workflow to cancel.
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 clearly states the action ('Cancel') and the target resource ('a running workflow'). It distinguishes itself from sibling workflow tools like trigger_workflow, get_workflow_status, and rerun_failed_jobs, making its purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool instead of alternatives like waiting for the workflow to finish or using rerun_failed_jobs. The description does not mention any prerequisites, side effects, or situations where cancellation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and format, omitting details about the 'graph' parameter, side effects, return value, or required input format. This is a significant gap for a tool with no other context.
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 a single, direct sentence with no superfluous words. It is appropriately sized for a simple tool and front-loads the key action and output format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is too sparse for a tool with no annotations, no output schema, and an undocumented parameter. It does not explain what 'graph' refers to, how the output is returned, or any usage context, making it incomplete for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'graph' with no description, and the tool description does not clarify its meaning or expected format. With 0% schema description coverage, the description fails to compensate, leaving the agent without essential parameter semantics.
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 clearly states the tool's purpose: exporting a citation network to BibTeX format. The verb 'Export' plus the resource 'citation network' and format 'BibTeX' distinguish it from sibling tools like export_json and import_csv.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not mention when to use this tool over alternatives, nor does it specify any prerequisites or exclusions. The purpose is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description must disclose behavioral traits but only states 'Get', implying a read operation without detailing side effects, authentication needs, or return format. The behavior of the optional run_id parameter is not explained, leaving significant 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?
The description is a single, focused sentence that wastes no words. However, it is somewhat under-specified, and additional context could be added without significant bloat, so it does not earn a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one optional parameter and no output schema, the description is not complete. It fails to clarify behavior when run_id is omitted, what status information is returned, or how it fits with sibling workflow tools, leaving critical gaps for an agent.
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?
The schema already describes run_id as 'Optional run ID' with 100% coverage. The description adds no parameter information beyond the schema, so the baseline of 3 applies for high schema coverage.
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?
The description uses the specific verb 'Get' and the resource 'CI/CD workflow status', clearly indicating a read operation. It is distinct from siblings like trigger_workflow and cancel_workflow, though it does not specify whether it returns a single run or all runs, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention how run_id filters results or what happens when it is omitted, and there is no differentiation from related tools like get_dora_metrics or analyze_workflow_failures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It does not state whether removal is permanent, what happens to edge attributes, or what the return value is, leaving significant ambiguity for a mutation operation.
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 a single concise sentence with no unnecessary words. It is appropriately sized for a simple tool, though it sacrifices content for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a graph mutation tool with no annotations and no output schema, the description omits critical details such as return values, in-place mutation semantics, and expected edge format. It is not sufficient for an agent to invoke it reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the 'edges' array format or what the 'graph' string refers to. It adds no meaning beyond the schema's property names.
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 clearly specifies the action ('remove') and the resource ('edges') within a graph, which is specific and distinguishes it from sibling tools like 'remove_nodes' and 'add_edges'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as 'remove_nodes' or 'add_edges'. There is no context about prerequisites or situations where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'Set attributes.' It does not clarify whether existing attributes are overwritten, whether edges are created if missing, side effects, error handling, or permission requirements. This is a significant transparency gap.
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 a single concise sentence with no fluff. It is appropriately short for a simple tool, though it could include more useful detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool involves a nested parameter structure and has no annotations or output schema. The description is too minimal to provide complete context for an AI agent, lacking information about return values, expected errors, edge cases, or operational behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%: only the 'attributes' parameter has a minimal description ('List of {source, target, attr, value}'), while 'graph' has none. The tool description adds no parameter-level meaning, failing to compensate for the low coverage. It doesn't explain what types 'graph' expects or the semantics of attr/value.
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 is a clear, specific verb+resource statement: 'Set attributes on one or more edges.' It establishes the exact action (set), target (edges), and scope (one or more). It also distinguishes from sibling tools like set_node_attributes by explicitly stating edges.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites such as the graph existing or edges already being present. Usage is only implied by the name/description, with no explicit when or when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states the action. It does not indicate whether attributes are overwritten or merged, whether nodes must already exist, what error behaviors occur, or what side effects (if any) are produced. This is a significant transparency gap for a mutating tool.
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 a single, tightly worded sentence with no wasted words. However, it is so minimal that it borders on under-specification rather than conciseness; it skips essential context while remaining easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a mutation tool with no annotations and no output schema, so the description carries full responsibility for explaining return values, side effects, and prerequisites. It does none of this, leaving the agent without critical information for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 50%: the 'attributes' parameter has a helpful inner description ('Map of node -> {attr: value}'), but the required 'graph' parameter is entirely undocumented. The tool description adds no extra meaning beyond the schema, failing to clarify what the graph identifier refers to or how attribute values are structured.
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 uses a specific verb ('Set') and a clear resource ('node attributes'), immediately distinguishing it from sibling tools like set_edge_attributes and get_node_attributes. The phrase 'on one or more nodes' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_node_attributes or set_edge_attributes. The description does not mention any context, prerequisites, or exclusions, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention error handling for cyclic graphs, the return format, or determinism, which are critical for a topological sort tool.
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 a single concise sentence that front-loads the core purpose without extraneous words. It earns its place and is easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description lacks essential invocation details such as input format, return type, and error conditions. It is minimal and leaves the agent guessing about how to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'graph' is a string with no schema description coverage, and the description does not clarify whether it expects a graph ID, adjacency list, or other representation. This ambiguity is not compensated by the description.
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 clearly states a specific operation: returning a topological ordering of a directed acyclic graph. This distinguishes it from sibling tools like shortest_path or pagerank by naming a distinct graph algorithm and the required input type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites (e.g., the graph must be acyclic). It simply states what the tool does without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only lists measure names and provides no information about return format, the required 'graph' parameter semantics, default behavior when 'measures' is omitted, or any side effects or prerequisites.
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?
A single sentence with no filler. It is front-loaded with the verb 'Calculate' and directly specifies the resource and supported measures. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and an underdocumented graph parameter, the description is too sparse. It does not explain the return value, the nature of the graph input, or behavior when 'measures' is absent, which would be critical for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; 'measures' has a description but 'graph' does not. The description adds no additional meaning for the graph parameter and only repeats the allowed measure values already present in the schema.
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 clearly states the tool calculates multiple centrality measures and enumerates them (degree, betweenness, closeness, eigenvector). This verb+resource+scope effectively distinguishes it from sibling tools like degree_centrality and betweenness_centrality.
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 plural 'multiple' and the list of measures imply this tool is for computing several centralities at once, but there is no explicit statement of when to use it versus individual centrality tools or any alternatives/exclusions. Usage context is inferable but not directly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits itself. The verb 'Get' implies a read-only operation, which is helpful. However, it does not describe what data source it reads from, whether it computes metrics on demand, or what output format to expect.
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?
A single, front-loaded sentence that states the action and domain. Every word earns its place with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite low complexity (no parameters), the lack of an output schema places the burden on the description to explain what the tool returns. 'DORA metrics' is a known set but the description does not specify which metrics are provided, whether they are per-repository or global, or if any setup is required. The description is too thin for an agent to confidently invoke and interpret results.
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?
The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information but does not need to. Baseline for 0 params is 4, which is appropriate here.
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?
The description uses a clear verb ('Get') and specific resource ('DORA metrics') with a scoping phrase ('for CI/CD performance'). It distinguishes itself from sibling workflow tools like trigger_workflow and get_workflow_status, though it does not enumerate which DORA metrics are included.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many workflow and analysis siblings, the description offers no context about typical scenarios or prerequisites (e.g., whether a graph or workflow is needed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'Calculate' implies a read-only operation, but no details are given about output format, performance considerations on large graphs, or whether the graph is modified. This is minimal transparency beyond the purpose.
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 a single, concise sentence that front-loads the core action and includes relevant examples. Every word contributes to the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, no annotations, and a minimal description. For an analysis tool of this scope, the lack of information about return values, input format, and any caveats makes the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'graph' of type string, but the description does not explain what format is expected (e.g., graph ID, name, object). Since schema description coverage is 0%, the description fails to compensate, leaving the parameter ambiguous.
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 provides a clear verb ('Calculate'), a specific subject ('graph statistics'), and concrete examples (density, diameter, degree distribution). This distinguishes it from sibling tools like pagerank or centrality measures, which focus on specific algorithms.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not specify when to use this tool versus alternatives. There are no explicit exclusions or references to other tools, leaving the agent to infer from the listed statistics. Sibling tools like 'get_info' or 'centrality_measures' may overlap, but no guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It fails to mention whether the import replaces an existing graph, whether the graph must already exist, or any side effects. The only behavioral detail is the CSV format, which is more about parameter semantics than behavior. Significant gaps in transparency exist.
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 a single, front-loaded sentence that directly states the core purpose and format. There is no wasted verbiage, and every word contributes to understanding. This is an example of concise, effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 parameters, no output schema, and no annotations. The description is minimal and fails to cover prerequisites, return values, or behavior beyond the basic format. It is not complete enough for an agent to fully anticipate the tool's behavior without further inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains the format for csv_data ('source,target per line') but provides no information about the 'graph' parameter or the 'directed' flag. Since two of three parameters remain unexplained, the description insufficiently compensates for the lack of schema descriptions.
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 clearly states the tool's function: 'Import graph from CSV edge list' with specific format details. This distinguishes it from sibling tools like add_edges or create_graph by focusing on bulk import from CSV. The verb 'import' and resource 'graph' are specific and unambiguous.
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 implies usage for CSV edge list imports by stating the format, but it does not explicitly contrast with alternatives like add_edges or create_graph, nor does it mention when not to use it. The guidance is implied rather than explicit, so it earns a 3.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses that the operation produces a 'new graph' (indicating non-destructive composition) and specifies union semantics, but it does not address attribute merging, conflict resolution, or validation behavior.
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 a single, front-loaded sentence that efficiently communicates the tool's core action without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the tool's apparent simplicity, the description lacks essential details for correct invocation: parameter roles, input graph prerequisites, and behavior regarding node/edge attributes are unaddressed, leaving the description incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All three parameters are strings with no schema descriptions and 0% schema coverage; the description does not map graph_a, graph_b, or new_graph to their roles or expected formats, adding no meaningful parameter information.
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 uses a specific verb 'compose' and identifies the resource ('two graphs') and result ('new graph'), clearly distinguishing from siblings like create_graph or subgraph.
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 implies usage for merging two graphs but does not explicitly state when to prefer it over alternatives (e.g., adding nodes/edges manually) or provide prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only, nor does it disclose what 'summary info' includes or whether results are limited. The verb 'list' implies non-mutation, but lacks behavioral details.
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 a single sentence with no wasted words: 'List all stored graphs with summary info'. It is concise, front-loaded with the action, and every word adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is incomplete for a tool with no output schema and no annotations. It fails to specify what 'summary info' includes, whether there is pagination, ordering, or any limits. The agent is left guessing about the return format.
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?
The tool has zero parameters, and the schema is trivially 100% covered. Since there are no parameters to explain, the baseline of 4 applies, and the description adds no unnecessary parameter information.
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 'List all stored graphs with summary info' uses a specific verb ('list'), identifies the resource ('graphs'), and scopes it to 'all stored', which clearly distinguishes it from sibling tools like get_info that likely target a single graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It does not mention that get_info is for individual graphs or that this is the primary listing tool, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the use of the CrossRef API (implying an external network read), but it does not explain error behavior, rate limits, or the structure of the returned metadata. Some behavioral context is provided, but not richly.
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 a single, front-loaded sentence with no redundant text. It communicates the action, resource, and method efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema. The description states it returns 'publication metadata' but does not specify the metadata structure, error conditions, or whether additional fields are available. Adequate for a simple resolver, but with clear gaps in return-value detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (doi) with 0% description coverage. The description merely repeats the term 'DOI' without clarifying the expected format (e.g., bare DOI vs. full URL) or providing examples, adding minimal value beyond the schema.
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 uses a specific verb 'Resolve' with a clear resource ('DOI') and outcome ('publication metadata'). It also names the external API (CrossRef), which distinguishes it from sibling tools that focus on graph operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention exclusions, prerequisites, or suggested contexts, leaving the agent to infer usage from the name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavior: it extracts an induced subgraph (i.e., preserves edges among selected nodes) and stores it as a new graph, implying non-destructive operation. However, with no annotations, it fails to mention error handling, whether an existing new_graph is overwritten, or validation of node existence.
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?
One sentence, 11 words, front-loaded with the main action and outcome. Every word earns its place, with no redundant 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 simple 3-parameter tool with no output schema, the description covers the core concept and non-destructive nature. It lacks explicit return value information, but the operation is straightforward enough that this is a minor gap.
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?
The description implicitly maps parameters: 'graph' is the source, 'nodes' are the selection set, and 'new_graph' is the destination. With 0% schema coverage, this is helpful but still leaves parameter types and constraints unexplained.
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?
The description uses a specific verb ('Extract') and resource ('induced subgraph') with a clear outcome ('store it as a new graph'). It distinguishes itself from sibling tools like remove_nodes by emphasizing the creation of a new graph, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as remove_nodes or merge_graphs. There is no mention of use cases, prerequisites, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It implies a read-only operation ('Export') and specifies the output structure (node-link format), which adds behavioral context. However, it does not disclose error conditions (e.g., missing graph), return type details (string vs. object), or whether the operation is synchronous. Basic transparency is present, but edge cases are unaddressed.
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 a single sentence of six words, front-loaded with the action and outcome. Every word contributes meaning, with no filler or redundant information. It is efficiently concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description covers the core function and output format, but lacks essential context: how the parameter is used, the exact JSON structure beyond 'node-link', and any usage conditions. Given the large sibling set, additional guidance on when to choose this export tool would improve completeness. It is minimally viable but has clear gaps.
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 coverage is 0%, so the description must compensate. The single parameter 'graph' is vaguely clarified by the phrase 'Export graph', indicating it is the graph to be exported. However, the description does not specify whether this is an ID, name, or object, nor the expected format. The parameter's purpose is inferable but not explicitly defined.
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 clearly states the action ('Export'), the object ('graph'), and the output format ('JSON in node-link format'). This differentiates it from siblings like export_bibtex, which exports a different format. The verb-object-format structure leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, such as needing an existing graph, nor does it note that this is the tool for programmatic interchange of graph data. No exclusions or alternative tool references are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It does explain the two distinct modes (cycle basis vs DAG check), which is beyond the name's implication. However, it does not specify the return format (e.g., boolean vs cycle list), input graph string format, or how directedness is determined, leaving important 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core purpose ('Detect cycles in a graph') and adds a parenthetical clarification. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and a single underdocumented parameter, the description is too sparse. It omits the return type, input graph representation, and any usage caveats, which are essential for an AI agent to invoke this tool correctly and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter 'graph' (string) with 0% description coverage, so the description must compensate. It does not explain what string format is expected (e.g., adjacency list, edge list, GraphML), which is critical for correct invocation. This is a significant gap, especially since it is the only parameter.
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 uses a specific verb ('Detect cycles') and resource ('graph'), and clarifies behavior for undirected (cycle basis) vs directed (DAG check) graphs. This distinguishes it from sibling tools like topological_sort or graph_statistics, making the purpose unambiguous.
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 clearly indicates the tool's context by explaining that it behaves differently for undirected and directed graphs, which implies when to use it (e.g., for DAG checking on directed graphs). However, it does not explicitly mention alternatives or exclusions, but the behavioral distinction provides enough guidance for a knowledgeable user.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![networkx-mcp-server MCP server](https://glama.ai/mcp/servers/brightlikethelight/networkx-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/brightlikethelight/networkx-mcp-server)

Score Badge

Copy to your README.md:

[![networkx-mcp-server MCP server](https://glama.ai/mcp/servers/brightlikethelight/networkx-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/brightlikethelight/networkx-mcp-server)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/brightlikethelight/networkx-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server