Skip to main content
Glama
raultov

knot

by raultov
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Hybrid

List HTTP endpoints

list_endpoints
Read-onlyIdempotent

List HTTP endpoints from indexed repositories to find which routes a service exposes and which handler serves a given method and path. Filter by repository, HTTP method, or path prefix.

Instructions

Read-only catalogue of the HTTP endpoints the indexed repositories serve, each with the handler method it routes to. Answers 'which endpoints does this service expose?' and 'which handler serves GET /api/owners/42?'.

Coverage: Java and Kotlin handlers annotated for JAX-RS (class/method @Path + @GET/@POST/@PUT/@DELETE/@PATCH/@HEAD/@OPTIONS) or Spring MVC (class @RequestMapping + @GetMapping/@PostMapping/@PutMapping/@DeleteMapping/@PatchMapping or @RequestMapping(method = ...)). Paths join the class-level and method-level paths, resolve string constants declared in the same file, and drop path-variable patterns ('{id: [0-9]+}' → '{id}'); a part that cannot be resolved is shown as ''. Paths are relative to the application: the context path (server.servlet.context-path, @ApplicationPath) is deployment configuration and is not applied. 'ANY' marks a @RequestMapping without 'method'. Declarative HTTP clients (@FeignClient, @RegisterRestClient interfaces) are not endpoints.

Usage: Use this for API-surface questions; then run 'find_callers' on the handler FQN for its callers, or on an endpoint name ('GET /api/owners/{id}') for the handler it routes to. Every endpoint is also an 'http_endpoint' entity reachable from 'search_hybrid_context' and 'explore_file', and a handler's 'find_callers' lists the endpoints routing to it under 'HTTP routes'.

Behaviour & Return: Read-only query with no side effects. Returns a Markdown table with columns: Method, Path, Handler, Location, Repository, ordered by (repository, path, method). At most 1000 rows; the reply states when more matched. When nothing matches, returns 'No HTTP endpoints matched.'.

Parameter guidance: 'method' is optional and case-insensitive ('GET'); 'ANY' endpoints match every method. 'path' is optional and matches segment by segment as a prefix ('/api/owners' matches '/api/owners/{id}' but not '/api/ownership'); an endpoint's '{variable}' segment matches any concrete segment, so a concrete URL path finds its endpoint. 'repo_name' scopes the catalogue.

Input Schema

NameRequiredDescriptionDefault
pathNoOptional path filter, matched segment by segment as a prefix (e.g. '/api/owners'). An endpoint's '{variable}' segment matches any concrete segment, so '/api/owners/42' finds 'GET /api/owners/{id}'.
methodNoOptional HTTP method filter, case-insensitive (e.g. 'GET'). Endpoints mapped to every method ('ANY') always match.
repo_nameNoOptional but HIGHLY RECOMMENDED: repository scope. Accepts a single repository name (`'my-repo'`), a comma-separated list (`'repo-a,repo-b'`), or `'all'` (or `'*'`) to query every indexed repository.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.12.0

TDQS

A4.7/5.0
Behavior5/5

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

Although annotations already declare readOnlyHint, idempotentHint, and non-destructive, the description adds substantial behavioral context: supported frameworks, path normalization rules, context-path omission, 'ANY' semantics, exclusion of declarative clients, return table format, row limit of 1000, and the exact no-match message. This goes well beyond the structured annotations.

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 long but well-structured, front-loading purpose and usage before moving to coverage rules and return format. Each section earns its place given the complexity of path resolution and framework support; there is no filler.

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?

With no output schema, the description fully specifies the return shape: a Markdown table with named columns, ordering, row cap, and fallback message. Combined with the coverage rules and usage guidance, an agent has everything needed to call the tool correctly and interpret its output.

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 three parameters in detail. The description's 'Parameter guidance' section largely restates the schema: method case-insensitivity and 'ANY' matching, path prefix and variable matching, and repo_name scoping. It adds marginal value but does not compensate for any coverage gap because there is none.

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?

State a specific verb and resource ('Read-only catalogue of the HTTP endpoints the indexed repositories serve') and immediately distinguish the tool from siblings by naming the questions it answers. The description also clarifies scope (Java/Kotlin handlers) and what is not included (declarative clients), so an agent can confidently select it over find_callers or search_hybrid_context.

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?

Explicitly says 'Use this for API-surface questions' and then names the next step: run 'find_callers' on the handler FQN or on an endpoint name. It also notes alternative access paths via 'http_endpoint' entities in search_hybrid_context and explore_file, giving clear when-to-use guidance and alternatives.

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