Skip to main content
Glama
ozgurcd

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_tests

Read-onlyIdempotent

Find Go tests that exercise a named symbol directly or through router/callback paths to check coverage before editing code.

Instructions

Find test functions in *_test.go files that statically exercise a named symbol, or list all attributed test edges when no symbol is given. Direct mode accepts Receiver.Method (including pointer receivers) or a full stable symbol ID. By default this preserves the direct-edge result contract. Set transitive=true with a required symbol to return gograph.tests.v1 reverse attribution, including exact/possible resolution, depth, and a representative stable-ID path from every reaching test; exact_only omits uncertain paths and package disambiguates the selected product symbol. The MCP server checks freshness before this call and refreshes in the current requested analysis mode. Read-only; no side effects. WHEN TO USE: Before editing a function — use transitive=true for router/callback-mediated coverage and direct mode for concrete test call sites. NOT TO USE: For test helper infrastructure (use gograph_fixtures); for running tests or proving runtime coverage. RETURNS: Direct result rows by default, or a versioned reverse-transitive report when requested.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
symbolNoThe symbol name to find tests for (optional)
packageNoWith transitive=true, optional exact Go package name used to disambiguate the selected symbol
exact_onlyNoWith transitive=true, omit paths containing possible edges
transitiveNoReturn reverse-transitive test attribution; requires symbol

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.7.5
    • addedInput schema / properties / exact_only
      Added value: +{
+  "description": "With transitive=true, omit paths containing possible edges",
+  "type": "boolean"
+}
    • addedInput schema / properties / package
      Added value: +{
+  "description": "With transitive=true, optional exact Go package name used to disambiguate the selected symbol",
+  "type": "string"
+}
    • addedInput schema / properties / transitive
      Added value: +{
+  "description": "Return reverse-transitive test attribution; requires symbol",
+  "type": "boolean"
+}
  2. First observedv1.0.0

TDQS

A4.5/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real behavior beyond that: the server checks freshness and refreshes in the requested analysis mode, and the return contract changes shape when transitive=true (versioned report with exact/possible resolution and depth). It stops short of describing rate limits or size/pagination of large result sets.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then modes, then WHEN/NOT/RETURNS blocks. Slightly redundant — 'By default this preserves the direct-edge result contract' is restated in the RETURNS block — but nearly every sentence carries routing or contract 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?

No output schema exists, so the description must describe returns; it does so at a high level (direct rows vs versioned reverse-transitive report with resolution/depth/path). Adequate for a 4-param, optional-arg tool, though field-level detail of the returned rows is absent.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious semantics: transitive requires a symbol, package only applies with transitive=true, and exact_only omits uncertain paths. The cross-parameter dependencies go beyond the per-parameter schema text.

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?

States a specific verb+resource ('find test functions in *_test.go files'), distinguishes two modes (direct vs transitive), and names the sibling it is not (gograph_fixtures). An agent can separate it from the other ~60 graph tools without opening the schema.

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

Usage Guidelines5/5

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

Explicit WHEN TO USE ('Before editing a function — transitive=true for router/callback-mediated coverage, direct mode for concrete test call sites') and NOT TO USE clauses with named alternatives (gograph_fixtures for helpers; not for running tests or runtime coverage). Nothing is left to inference.

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

Deploy Server

Other Tools