Skip to main content
Glama
ozgurcd

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_implementers

Read-onlyIdempotent

Find all concrete Go structs that implement a named interface. Merges production and test results to trace polymorphism, locate dependency injection points, or find mocks.

Instructions

Find all concrete structs that implement a named Go interface. Type-checked production results are merged with AST-discovered implementations from test files because production package loading excludes test variants. The MCP server checks freshness before this call and refreshes in the current requested analysis mode; precise and precise_fallback graphs retry CHA/SSA after source changes. Read-only; no side effects. Set test_only=true to restrict to structs in *_test.go files (mocks/stubs). WHEN TO USE: When tracing polymorphism, locating dependency injection points, or finding all mock implementations of an interface. NOT TO USE: For interfaces a struct satisfies — inverse direction (use gograph_interfaces instead); for struct fields (use gograph_fields). RETURNS: List of implementing struct names with package paths and file locations; empty when no struct implements the interface.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows per page; the byte budget may return fewer.
cursorNoOpaque next_cursor for the same graph snapshot and result selection.
interfaceYesThe name of the interface (e.g., 'AuthService')
test_onlyNoIf true, return only structs defined in test or mock files (replaces gograph_mocks)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.7.5
    • addedInput schema / properties / cursor
      Added value: +{
+  "description": "Opaque next_cursor for the same graph snapshot and result selection.",
+  "maxLength": 128,
+  "type": "string"
+}
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 100,
+  "description": "Maximum rows per page; the byte budget may return fewer.",
+  "maximum": 200,
+  "minimum": 1,
+  "type": "integer"
+}
  2. Addedv1.5.3
  3. Removedv1.5.3
  4. First observedv1.0.0

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations that already declare read-only/idempotent behavior, the description discloses non-obvious mechanics: production type-checked results are merged with AST-discovered test implementations because package loading excludes test variants. It also explains freshness checking and CHA/SSA retry behavior for precise graphs, which materially affects result interpretation.

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 front-loaded with purpose and uses clear WHEN TO USE / NOT TO USE / RETURNS sections. It is slightly overstuffed, and 'Read-only; no side effects' duplicates the annotations, but the additional behavioral details earn most of their space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex graph-analysis tool with no output schema, the description covers purpose, behavioral mechanics, alternatives, and return format. An agent has enough context to call it correctly and interpret the result.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents all four parameters including limit, cursor, interface, and test_only. The description adds only a brief restatement of test_only's purpose, which is already present in the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence states a specific verb and resource: 'Find all concrete structs that implement a named Go interface.' It explicitly distinguishes itself from siblings by naming gograph_interfaces for the inverse direction and gograph_fields for struct fields, so an agent can route correctly without opening other schemas.

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?

The description contains explicit WHEN TO USE and NOT TO USE sections. It names concrete scenarios (tracing polymorphism, dependency injection points, mocks) and points to the exact alternative tools for excluded cases (gograph_interfaces, gograph_fields).

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