Skip to main content
Glama
Sign In

Carrick

by io.github.carrick-tools
OverviewDiscussionsAdmin

List a service's operations

get_api_endpoints
Read-onlyIdempotent

List the operations one service exposes: HTTP endpoints, GraphQL fields, socket events. Call it when unsure which operations a service has or whether one exists. For the types of a known endpoint, use get_endpoint_types. When you already know the operation and need its producer or its consumers, use get_operation.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "service": "<service>"
    },
    "name": "get_api_endpoints"
  }
}

Input Schema

NameRequiredDescriptionDefault
repoNoYour repo as owner/repo (git remote) or just the repo name. Resolves which Carrick project to query.
methodNoFilter by operation label: HTTP method (GET, POST), GraphQL kind (QUERY, MUTATION, SUBSCRIPTION), or socket direction (CLIENT->SERVER, SERVER->CLIENT, UNKNOWN). UNKNOWN also selects HTTP routes whose verb the scan could not read; each row names its protocol.
projectNoCarrick project slug to query. Omit to auto-resolve via `repo`, or omit both when the workspace has one project.
serviceYesService name to look up (fuzzy match by repo name, service name, or trailing segment)
path_containsNoFilter operations whose path, field, or event name contains this substring

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observed

TDQS

A4.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds that results span three protocol families, which is useful scope context, but says nothing about result volume, pagination, or how filters combine with the service lookup. With annotations carrying the safety burden, this is adequate rather than rich.

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?

Three short sentences with zero filler: capability first, then the primary trigger, then two routing alternatives. The most decision-relevant information is front-loaded.

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 read-only discovery tool with five fully documented parameters and no output schema, the description covers purpose, trigger, and sibling routing adequately. It stops short of describing the shape or size of returned operation rows, which an agent would need to plan a follow-up call, so it is strong but not exhaustive.

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% and each parameter is documented in detail, including the method label vocabulary and UNKNOWN handling, so the description can lean on the schema. The description adds no parameter guidance of its own, making baseline 3 correct.

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 and resource ('List the operations one service exposes') and enumerates the concrete result kinds: HTTP endpoints, GraphQL fields, socket events. It names the two nearest siblings (get_endpoint_types, get_operation) with the condition that distinguishes them, so an agent can route without opening a 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 trigger ('when unsure which operations a service has or whether one exists') plus two named alternatives with their own selection criteria: get_endpoint_types for types of a known endpoint, get_operation for producer/consumers of a known operation. That is the full when/when-not/alternative triad.

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

All Carrick toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources