Skip to main content
Glama
ozgurcd

gograph

by ozgurcd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

gograph_httpcalls

Read-onlyIdempotent

List bounded pages of static net/http Get, Post, PostForm, Head, and NewRequest evidence. Filter by method, URL, or function; returns file/line details without runtime values.

Instructions

List a bounded page of HTTP evidence from imported, unshadowed net/http Get/Post/PostForm/Head calls and possible NewRequest/NewRequestWithContext construction. Client receiver methods and arbitrary URL-building functions are not inferred. Static strings and bounded lexical base + static suffix expressions are recorded; runtime environment values are never read. Construction is not dispatch proof. Workspace http_clients may explicitly map bases or env:KEY to scoped logical authorities; unresolved destinations remain workspace diagnostics. The MCP server refreshes source analysis before this call. Read-only. Optional term matches method, URL/base, or function. RETURNS: gograph.results.v1 rows with file/line and dynamic base/suffix or request-only evidence in detail, plus total/returned/truncated/next_cursor. For server routes use gograph_routes.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
termNoOptional filter term (matches method, URL, or function name — e.g., 'POST' or 'api.example.com')
limitNoMaximum rows per page; the byte budget may return fewer.
cursorNoOpaque next_cursor for the same graph snapshot and result selection.

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. Addedv1.4.80

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds valuable non-obvious behavior: 'The MCP server refreshes source analysis before this call,' 'runtime environment values are never read,' pagination via 'next_cursor' tied to a 'same graph snapshot,' and the caveat that 'Construction is not dispatch proof.' That is substantive context beyond annotations.

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 dense but front-loaded: lead sentence states purpose, then scope exclusions, semantics, behavior, and return shape. Every sentence earns its place, though the wording is dense enough that a reader may need to parse carefully; it avoids filler.

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?

Given three params, no output schema, and a read-only bounded list tool, the description supplies the needed return shape (gograph.results.v1 rows, total/returned/truncated/next_cursor), pagination behavior, and scoping caveats. It is nearly complete for invocation, with minor gaps around filtering semantics beyond the term option.

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 documents all three parameters with semantics (term matches method/URL/function, limit byte budget, cursor snapshot bounds). The description adds little beyond what the schema provides, so baseline 3 applies.

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

Purpose5/5

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

The description precisely states the resource (HTTP evidence from net/http calls) and the exact syntactic constructs captured (Get/Post/PostForm/Head, NewRequest variants) while bounding scope. It explicitly names the sibling it replaces for server routes ('For server routes use gograph_routes'), making it distinguishable from the large sibling set.

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 states what is included (static strings, bounded lexical base + static suffix) and what is excluded ('Client receiver methods and arbitrary URL-building functions are not inferred'). The routing pointer to gograph_routes is an explicit alternative. However, it doesn't describe when an agent should reach for this tool over, e.g., gograph_literals or gograph_endpoint, leaving some selection 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