Skip to main content
Glama
Sign In
Maven Decoder MCP Server

Maven Decoder MCP Server

by salitaba
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

find_usage_examples

Locate real-world usage examples for any class or method in test jars, with pagination and optional method filtering to understand how to call APIs.

Instructions

Find usage examples of classes/methods in test jars

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": {
      "class_name": "<class_name>"
    },
    "name": "find_usage_examples"
  }
}

Input Schema

NameRequiredDescriptionDefault
pageNoPage number for pagination
limitNoMaximum results to return
class_nameYesClass name to find usage for
method_nameNoMethod name to find usage for
search_testsNoSearch in test jars
items_per_pageNoItems per page

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

B3.2/5.0
Behavior2/5

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

No annotations are present, so the description carries the full burden of explaining behavior. It states that the tool 'finds usage examples in test jars,' but it does not disclose whether this is a read-only operation, what the output looks like, how pagination behaves, or what happens when no examples are found. These behavioral gaps are notable for a tool with no output schema and no 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 a single, concise sentence that front-loads the core purpose. There is no redundant or filler content, and it is appropriately sized for what it communicates.

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

Completeness2/5

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

Given six parameters, no annotations, and no output schema, the description is too minimal to be fully actionable. It does not explain return values, pagination semantics, or how this tool fits among the sixteen listed siblings. An agent would likely need additional inference or experimentation to invoke it correctly for non-default cases.

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 each parameter clearly. The description adds little beyond mapping 'classes/methods' to class_name and method_name, and 'test jars' to search_tests. It does not clarify the relationship between page, limit, and items_per_page or their effective behavior.

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 states a clear verb and resource: 'Find usage examples of classes/methods in test jars.' It is specific enough to distinguish this tool from siblings like extract_class_info or extract_method_info, which focus on structural details rather than usage examples. The scope 'test jars' further narrows the purpose.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus the many sibling tools. The description does not mention alternatives, exclusions, or conditions that would help an agent choose between find_usage_examples and similar search/analysis tools. The only implied context is that test jars are the search target, but no explicit usage guidance is provided.

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