Orihime

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.1
Disambiguation4/5
Most tools have clearly distinct purposes, but there is overlap among taint analysis tools (e.g., find_taint_flows, find_taint_sinks, find_taint_paths) and performance analysis tools (e.g., find_complexity_hints, find_hotspots), which could cause misselection despite detailed descriptions.
Naming Consistency4/5
The majority of tools follow a consistent verb_noun pattern (e.g., find_callees, list_repos), but 'blast_radius' uses a metaphor rather than a verb, and 'ingest_perf_results' uses an abbreviation, deviating slightly from the norm.
Tool Count4/5
With 32 tools, the count is on the higher side but still appropriate for the broad scope covering static analysis, security, performance, and repository management. Each tool addresses a specific need, so the surface is well-scoped.
Completeness3/5
The tool set covers many essential operations (indexing, call graph queries, security analysis, performance analysis), but there are notable gaps: no tools for deleting or updating indexed data, and no visualization or export functionality, limiting end-to-end workflows.
Average 4.2/5 across 32 of 32 tools scored. Lowest: 3.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 8, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the output format and input, but does not mention that it is a read-only operation or any side effects, leaving the agent uninformed.
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 concise with a clear Docstring structure (Args, Returns), front-loading the main purpose. No unnecessary words, but it could be slightly more structured.
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?
Despite lacking usage guidelines, the description sufficiently covers the tool's purpose, input, and output format. The presence of an output schema (not shown) reduces the burden, making it fairly complete for a simple query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero description coverage (0%), so the description must compensate. It mentions 'repo_name: Repository to query' which adds minimal detail beyond the parameter name, not enough for full clarity.
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 clearly states the tool returns methods/endpoints marked as entry points, listing specific types (HTTP handler, @KafkaListener, etc.), which distinguishes it from sibling tools like find_hotspots or list_endpoints.
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?
The description does not provide guidance on when to use this tool instead of alternatives, lacking context like when to prefer it over similar tools like list_endpoints or find_callees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool lists relationships and specifies return fields, implying read-only behavior, but lacks explicit safety notes or operational context.
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?
Two essential sentences: one for purpose, one for return format. No fluff, 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?
Tool has 1 parameter and output schema described. Lacks error handling or prerequisites but is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not mention the 'repo_name' parameter or add meaning beyond the schema title. Schema coverage is 0%, making the description insufficient for parameter understanding.
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 clearly states the verb 'List all', the resource 'JPA entity relationships', and the context 'in a repo'. It uniquely identifies the tool's function among sibling tools.
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?
No guidance on when to use this tool vs. alternatives, no prerequisites or limitations mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility. It explains the behavior (finding eager fetches and returning a list) and output structure, but it does not disclose whether the operation is read-only, whether it requires authentication, or if it has side effects. It is reasonable to infer read-only, but explicit confirmation is missing.
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 two sentences totaling ~25 words, with no fluff. The first sentence states the core purpose, and the second lists output fields. It is front-loaded and efficient.
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 one simple parameter and an output schema (which likely documents return structure), the description covers the main functionality well. The only shortcoming is the missing parameter explanation, but overall it is nearly complete for a straightforward analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter repo_name is not described in the description. With 0% schema description coverage, the description should compensate by explaining its meaning or format. While repo_name may be common across tools, the lack of any parameter guidance reduces clarity.
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 clearly states the tool's purpose: finding all EAGER fetch relationships, which are potential N+1 query sources. It also specifies the return format (list of dicts with specific fields). This distinguishes it from sibling tools like find_callees or find_taint_flows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is given. The description implies usage for analyzing ORM performance, but it does not mention prerequisites, alternatives, or exclusions. Among sibling tools with similar scope, more guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return format and empty-list behavior, but does not explicitly state whether the tool is read-only, list side effects, or require authentication. It is adequate but not thorough.
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 concise (about 7 lines) with a clear structure: purpose, args, returns. Every sentence adds value, no redundancy.
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 the tool's simplicity (2 params, no nested objects, output schema exists), the description covers the core functionality and return format. It misses potential prerequisites (e.g., repo indexing) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the 0% schema coverage by specifying allowed HTTP methods (case-insensitive) and the exact path pattern format (e.g., '/api/users/{id}'). This compensates well for the lack of schema descriptions.
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 clearly states the tool finds the handler method for an endpoint and all upstream callers, which is a specific and distinct purpose among sibling tools like find_callers or find_entry_points.
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?
No guidance is given on when to use this tool versus its siblings (e.g., find_callers or find_taint_flows). The description lacks context about prerequisites or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the algorithm (BFS), max depth, and that the starting class is excluded from results. However, it lacks information about side effects, authorization needs, or whether the tool is read-only. Given no annotations, this is adequate but incomplete.
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 very concise: two sentences plus a bullet list for the return format. It front-loads the main action and is well-structured.
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?
The description covers the essential details: purpose, parameters, behavior, and output. It could benefit from specifying the scope (e.g., which repositories) or whether it works cross-repo, but it is sufficient for a tool in a code analysis context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds crucial meaning: it explains that class_fqn is the starting point and max_depth has a default of 10. It also describes the return format beyond the schema.
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 clearly states that the tool walks the EXTENDS chain upward using BFS with max depth 10, and defines the return format. This distinguishes it from sibling tools like find_implementations which might find subclasses.
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?
No guidance is provided on when to use this tool versus alternatives, such as find_callees or find_implementations. The description does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the search order (Method then Class) and return format (dict or None). However, it omits details like scope (single repo?), index requirements, or handling of multiple matches.
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 extremely concise with no redundant content. Core purpose, argument semantics, and return structure are front-loaded in two clear sentences.
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 simple lookup tool with one parameter and an output schema, the description covers input, behavior, and output adequately. Missing details like case sensitivity or namespace format are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates by defining fqn as a fully-qualified name of a method or class, and explains the resolution logic. Adding example format would strengthen it further.
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 explicitly states the tool gets the source file path and line number for a method or class by fully-qualified name. It distinguishes itself from sibling tools like find_callees or search_symbol by focusing on location retrieval.
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?
No explicit guidance on when to use this tool versus alternatives like find_implementations or search_symbol. The description explains internal logic (tries Method first) but lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description explains the breakdown, latency estimation condition, and result sorting. However, it omits potential limitations (e.g., static analysis only, dependency on indexing), and does not state read-only nature.
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?
Description is well-structured with paragraphs for purpose, detail, parameters, and output. Slightly verbose but front-loaded with the core purpose. Could be shortened by merging parameter explanations.
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 the tool's complexity and lack of output schema, description provides return fields, sorting order, and prerequisite for latency calculation. Omits if results are real-time or cached, but overall comprehensive for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description adds meaning for both parameters. It explains repo_name as repository to query and min_total with default and purpose, complementing the sparse schema.
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?
Description clearly states 'Return entry-point methods ranked by I/O call count, with serial/parallel breakdown.' It identifies the specific resource and metric, setting it apart from siblings like find_entry_points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions when latency estimation is available (if perf data ingested) but lacks explicit when-not-to-use or comparisons to sibling tools like find_complexity_hints. No guidance on when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool uses a built-in sink registry merged with custom sinks from a YAML file, and it specifies the return format. However, it does not mention whether the tool is read-only, any performance implications, or required permissions, which are relevant for an analysis tool.
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 a well-structured docstring with clear Args and Returns sections. It is concise, though the SonarQube comparison could be seen as slightly extraneous. Overall, it front-loads the core purpose and details efficiently.
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 the single parameter and the presence of an output schema (not shown but indicated), the description provides sufficient context: it explains the return format and the merging logic. No significant gaps remain for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'repo_name' has 0% schema description coverage, but the description adds 'Repository to analyse', which clarifies its role beyond the schema's type-only definition. This adds meaningful value.
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 uses specific verb 'find' and resource 'calls to known dangerous sink methods', clearly distinguishing from siblings like 'find_reachable_sinks' or 'find_taint_flows'. It also specifies the context (repository) and mentions merging built-in and custom sinks, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for security analysis by referencing SonarQube's taint rules, but it does not explicitly state when to use this tool versus alternatives (e.g., 'find_reachable_sinks', 'find_taint_paths'). No when-not-to-use or comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the return format and the effect of the exclude_generated parameter, and mentions empty list conditions. However, it does not disclose side effects, error behavior, or performance implications. Without annotations, this is a minor gap.
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 very concise, using a clear Args/Returns structure. Every sentence is informative, with no redundancy or extraneous text.
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?
The description covers the return structure and parameter behavior well. However, it lacks details on whether the tool is read-only or has side effects, which would be helpful given no annotations. The mention of 'directly call' sufficiently clarifies scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: for method_fqn, it provides a concrete example of the required format; for exclude_generated, it explains its filtering behavior. This fully compensates for the schema's lack of parameter descriptions.
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 clearly states the tool finds all methods that directly call a given method, with a specific verb and resource. It distinguishes from sibling tools like find_callees by focusing on callers rather than callees.
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?
No explicit guidance is provided on when to use this tool versus alternatives. It does not mention when to use find_callees or other sibling tools, leaving the agent to infer from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the hop limit but has a slight contradiction between 'directly implement' and 'via IMPLEMENTS' hops, leaving ambiguity about transitive results. No permissions or performance mentioned.
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 short, structured with Args and Returns, and contains no fluff. However, the 'directly' vs 'hops' wording could be clarified.
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 the tool simplicity (one parameter) and presence of an output schema, the description covers the main use case and return format. It lacks detail on hop behavior and error cases, but is sufficient for a query tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the parameter format and example ('interface_fqn: FQN of the interface, e.g. com.example.WalletService'), compensating for the 0% schema coverage. This adds meaning beyond the schema's simple type declaration.
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 clearly states 'Find all classes that directly implement the given interface' with a specific verb and resource, along with the hop limit. This distinguishes it from siblings like 'find_superclasses' which does the reverse.
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 implies usage for finding implementing classes but does not explicitly mention alternatives or when not to use it. The hop limit provides some context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It discloses three filtering conditions and return fields. For a read-only query tool, this is sufficient transparency.
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?
Description is concise, well-structured with bullet points for conditions and return keys. Front-loaded with main purpose, every sentence adds value.
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 one simple parameter and no annotations, the description covers purpose, conditions, and return format. It is complete for the tool's complexity, though parameter explanation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter (repo_name) with 0% schema description coverage, but the description does not mention or explain the parameter at all. A simple explanation like 'the repository name to analyze' would be expected.
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?
Description states the tool returns 'confirmed taint flows' and explicitly differentiates from sibling 'find_taint_sinks' by listing three stricter conditions. Verb+resource is specific and clear.
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?
Explicitly states when to use this tool over 'find_taint_sinks' by noting it is stricter and lists conditions. Does not include when not to use, but the comparison is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It discloses that indexing makes data available to queries, explains parameter behavior (branch comparison, force re-parse), and describes return values (summary or error). However, it does not mention potential side effects, permissions, or whether re-indexing overwrites data. Acceptable but not thorough.
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 well-structured with explicit sections (overview, effect, args, returns). It is front-loaded with purpose. While somewhat lengthy, every sentence adds value and it remains efficient.
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 4 parameters and no output schema, the description covers input semantics, return structure, and effect on other tools. It lacks mention of prerequisites (e.g., repo must exist on disk) but is otherwise complete for an indexing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage from context, the description's Args section provides detailed explanations for all 4 parameters: repo_path is absolute path, repo_name is logical name, branch allows side-by-side comparison, force re-parses. This adds significant meaning beyond the schema.
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 clearly states 'Index a source repository into the Orihime knowledge graph' and explains the effect on sibling tools: 'After indexing, all other query tools will reflect the new data.' This distinguishes it from all sibling tools, which are query/analysis tools.
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 implies usage before querying, but does not explicitly state when not to use or provide alternatives. It gives clear context: using this makes data available to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden. It discloses that the tool creates nodes and edges (write operation), describes the return dict format including error handling, and specifies file format expectations. This provides adequate behavioral context, though it doesn't mention any side effects like overwriting existing data.
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 concise with a few sentences, front-loads the main purpose, and uses a clear structure with separate sections for args and returns. It is efficient but could be slightly more structured.
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 no output schema and no annotations, the description explains the return keys (ingested, matched_methods, unmatched, error) and the required parameters with format details. However, it does not mention prerequisites like whether the repo must already be indexed, and lacks details on potential error scenarios beyond the generic error dict.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must add value. It explains repo_name as 'logical name of indexed repository' and file_path as absolute path with allowed file extensions (.log, .xml, .json), providing meaning beyond the parameter names.
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 clearly states that the tool ingests Gatling/JMeter/JSON perf results files into the graph, creating PerfSample nodes and OBSERVED_AT edges. This is specific and distinct from sibling tools, which are primarily analysis or query tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for ingesting performance results but does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or prerequisites for using it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description explains the behavioral process: traversing call chains from HTTP handlers to outgoing calls via CALLS edges, and defines the output format. It does not mention prerequisites or side effects, but the read-only analytical nature is clear.
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 well-structured with a brief summary, detailed explanation, Args and Returns sections. It is concise, front-loaded with the main purpose, and every sentence adds value.
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?
The description covers purpose, parameters, and output schema well. It lacks mention of prerequisites like requiring the repo to be indexed, but overall it provides sufficient context for a complex analysis tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds descriptions for both parameters: repo_name as 'Repository to analyse' and max_depth with default and explanation. This adds meaningful context beyond the bare schema.
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 clearly states the tool finds taint paths from HTTP endpoint handler parameters to outgoing REST calls. It specifies the verb 'find', the resource 'taint paths', and narrows the scope to cross-service analysis, differentiating from generic taint analysis tools like find_taint_paths.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for cross-service taint analysis but does not explicitly state when to use it over siblings like find_taint_paths, find_taint_flows, or find_taint_sinks. No when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals behavioral traits: includes methods without perf data, details risk calculation, and specifies sorting order. However, it does not explicitly state if the operation is read-only or if it requires special permissions.
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 well-structured with clear sections for purpose, logic, args, and returns. It is reasonably concise, though the return format could have been omitted if an output schema were provided.
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?
The description fully covers the tool's behavior, parameter, and output format. Given the absence of an output schema, the description compensates by detailing the return fields and sorting. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 1 parameter with 0% description coverage. The description adds crucial meaning: 'The logical name of the indexed repository.' This clarifies the expected value beyond the bare schema field name.
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 clearly states the tool's purpose: 'Return methods ranked by composite risk: complexity_hint x p99.' It distinguishes from siblings like find_complexity_hints by combining complexity and latency into a composite risk score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the ranking logic and what methods are included (those with and without perf data). However, it lacks explicit guidance on when to use this tool versus sibling tools such as find_complexity_hints or find_callees.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies read-only behavior and lists return format, but does not disclose side effects, authentication needs, or performance implications. Basic transparency is present.
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 extremely concise: a single-line purpose and an Args/Returns section with no extraneous information. Every sentence is necessary and well-structured.
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 simple tool with one optional parameter and an output schema, the description covers usage and return format. It mentions 'indexed branches', which hints at prerequisites, but overall it is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds significant meaning: it explains the filtering logic and default value for repo_name, compensating for the schema's lack of detail.
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 clearly states the verb 'List' and the resource 'indexed branches' with an optional filter by repository. It distinguishes from sibling tools like list_repos and list_endpoints, which are different resources.
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 explains when to use the filter (repo_name) and the default behavior, but does not explicitly state when not to use it or compare with other tools. The context is clear enough for a straightforward listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It transparently explains the algorithm, including the formula for saturation_rps, and lists the return fields with meaning. It does not mention permissions, side effects, or data sources, but given the analytical nature, these omissions are minor. The description is largely adequate for understanding behavior.
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 well-structured with a clear first sentence and subsequent details including algorithm, formula, args, and returns. It is concise enough (roughly 100 words) without redundant information, but the inclusion of the formula could be simplified if the return fields already imply the computation. Still, it earns its place.
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?
Given the simplicity (single parameter, no annotations, output schema present), the description is complete. It explains the tool's purpose, algorithm, parameter meaning, and return structure including risk levels. No major gaps remain: an agent can confidently use this tool based solely on the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully. It defines the sole parameter repo_name as 'The logical name of the upstream repository to analyse,' adding semantic context beyond the schema's type and title. The Arg section in the description provides a clear explanation, satisfying the parameter semantics needs.
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 starts with a clear statement of what the tool does: 'Find upstream endpoints at cascade risk from saturated downstream services.' It then details the algorithm, including walking CALLS_REST edges and comparing saturation_rps to current_rps, which distinguishes it from sibling tools like blast_radius or find_callees that have different focuses.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the specific condition under which a risk is flagged (saturation_rps < current_rps), providing implicit guidance on when to use the tool. However, it does not explicitly contrast with alternatives (e.g., when to use find_callees vs. this tool) or state prerequisites like having perf data ingested, limiting the guidance value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool returns a list of dicts with a 'name' key, and handles missing repos or no dependencies gracefully by returning an empty list. It does not mention side effects, permissions, or rate limits, but for a read-only operation this is sufficient.
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 concise with two short sections: one for the main purpose and one for arguments/returns. Every sentence adds value, there is no fluff, and the key information is front-loaded.
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 tool with a single parameter and an output schema (implied by 'has output schema: true'), the description fully explains the return format and edge cases (empty list for not found or no dependencies). No further context is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter 'repo_name' has zero schema description coverage, but the description adds meaning by saying 'The logical name of the repository as indexed' and providing an example ('point-bank-bff'). This goes beyond the schema's 'Repo Name' title and clarifies what kind of name is expected.
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 clearly states the tool finds all repositories that the given repository directly depends on. It uses a specific verb ('find') and resource ('repositories that the given repository directly depends on'), and the name differentiates it from siblings like 'find_callers' and 'find_callees'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it versus alternatives like 'find_callees' or 'find_cascade_risk'. It mentions that an empty list is returned if the repo is not found or has no dependencies, which provides some context on outcomes, but lacks when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies a read-only operation but does not discuss auth, performance, or error handling.
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?
Description is concise with a clear docstring format (Args, Returns), no unnecessary words, and essential 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?
Covers core functionality, parameter, and return format. With an output schema and single optional parameter, it is largely complete, though it could mention error cases or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: explains the effect of repo_name, including the empty string default meaning 'all repos'. Schema coverage is 0%, so this is essential.
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 clearly states 'List all HTTP endpoints in the graph', identifying the verb and resource, and offers optional filtering by repository, distinguishing it from sibling tools like list_repos or list_branches.
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?
Provides clear context for the repo_name parameter and its default behavior, but does not explicitly state when to use this tool vs alternatives or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description transparently details the return value (list of dicts with keys) and the edge case of an empty list if no repos are indexed. No annotations are provided, but the description is clear.
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 extremely concise: one sentence for purpose, one for return format. No unnecessary information, front-loaded with the core action.
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?
Given zero parameters and the presence of an output schema, the description covers all necessary information: action, return format, and edge case. Completely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline score of 4 is appropriate. The description does not add parameter info (none needed).
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 explicitly states 'List all indexed repositories with their stats,' providing a specific verb and resource. It distinguishes itself from sibling tools (e.g., list_branches, list_endpoints) by focusing on repositories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. However, the description clarifies its scope (all repos) and return format, which implicitly suggests using it for a broad overview.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses the sorting order, the list of complexity patterns detected, and the effect of min_severity. It is transparent about the tool's behavior as a read-only query.
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 succinct, well-structured with summary, pattern list, args, and returns. Every sentence is purposeful.
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 the tool has 2 parameters and an output schema described, the description covers purpose, parameters, output format, and behavior. It lacks edge case handling but is sufficient for most queries.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description adds detailed semantics for min_severity with filtering logic, and describes repo_name minimally. This compensates well for the lack of schema descriptions.
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 clearly states it returns methods with complexity hints sorted by call in-degree, distinguishing it from sibling analysis tools that focus on different patterns like callers, callees, or taint flows.
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?
Provides clear usage context via the min_severity parameter behavior, but does not explicitly contrast with sibling tools; however, the naming and description make the use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses files scanned, query source, and return format including filtering of OK items. Lacks details on error handling or performance.
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?
Well-structured with summary, details, args, and returns. Slightly lengthy but each sentence adds value. Front-loaded with main purpose.
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?
Covers purpose, parameters, return values, and behavior. Missing error scenarios, but output schema handles status. Reasonably complete for a compliance check tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but description compensates fully: explains repo_name, allowed defaults, and license_overrides bypass mechanism, adding significant meaning beyond schema.
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?
Description clearly states 'Check dependencies in the repo for license compliance', providing a specific verb and resource. Distinct from sibling tools which focus on code analysis.
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?
Clear context on when to use (for license compliance) and what inputs are needed. No explicit alternatives mentioned, but no sibling tool serves the same purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it uses BFS traversal of CALLS edges in reverse, respects max_depth, excludes the changed method, and lists return keys (fqn, file_path, depth). This gives the agent a complete understanding of the tool's operation.
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 well-structured with clear Args and Returns sections, but it is slightly verbose. Every sentence adds value, though the format could be tightened. Overall, it communicates efficiently.
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 tool with three parameters and an output schema, the description covers all aspects: parameter meanings, behavior (BFS, exclusion of changed method), and return structure. It is complete and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must carry the burden. It explains method_fqn format with an example, max_depth default and max limit, and exclude_generated purpose. This adds significant meaning beyond the schema's type information.
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?
Description clearly states 'Find all methods transitively affected by changing the given method.' It specifies the action (find), resource (methods), and context (transitively affected by change), which distinguishes it from siblings like find_callers that likely provide only direct callers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly provide when or when-not to use this tool compared to alternatives. While the purpose is clear, it lacks guidance on when to choose this over sibling tools like find_cascade_risk or find_taint_flows, leaving the agent to infer from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the formulas, risk level thresholds, and return structure, providing sufficient transparency about tool behavior.
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 well-structured: starts with a summary, then formulas, risk levels, parameters, and returns. Every part earns its place without unnecessary verbosity.
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?
Given the presence of an output schema, the description adequately explains return values and tool usage. It covers all necessary aspects for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'repo_name' has 0% schema description coverage, but the description explains it as 'logical name of the indexed repository', adding meaningful context beyond the schema field.
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 clearly states it estimates capacity per endpoint using Little's Law, listing formulas. It uniquely identifies the tool's purpose among siblings, as no other sibling tool focuses on capacity estimation.
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 explains the functionality and provides formulas and risk levels, but does not explicitly state when to use it over alternatives. However, the context of sibling tools and the specific formulas make the usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the algorithm (BFS from entry points, filtering) and the return format with keys. This provides sufficient behavioral context, though it could mention side effects or performance considerations.
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 structured with sections (Args, Returns) and is front-loaded with the core purpose. It is slightly verbose but well-organized, with no wasted sentences.
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?
The description fully explains the tool's purpose, parameters, algorithm, and return format. Despite the lack of an explicit output schema, the returned keys are detailed. It provides complete context for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explicitly documents both parameters (repo_name and show_all) with their meanings and defaults, compensating for the 0% schema description coverage. It adds value by specifying the effect of show_all.
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 clearly states the tool returns taint sinks reachable from entry points via CALLS edges. It distinguishes itself from the sibling tool 'find_taint_sinks' by explaining the show_all parameter, making the purpose specific and unique.
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 explains when to use show_all=False vs True, and notes that show_all=True behaves like 'find_taint_sinks'. However, it does not explicitly state when not to use this tool or provide guidance on alternatives like 'find_taint_flows' or 'find_taint_paths'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool approximates second-order injection via structural analysis (write to JPA entity, read to sink), that it's not full data-flow, and that false positives are expected. This goes well beyond a simple 'detect' statement, though it could explicitly state it's read-only (implicit for analysis).
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 well-structured: a one-sentence summary first, then detailed explanation of the injection pattern and approximation, followed by limitations, args, and returns. Every sentence adds value, and the front-loading ensures key info is immediately visible. It's perfectly concise for the tool's complexity.
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?
The description fully explains the detection approach, limitations (structural approximation, false positives), and output format. The output schema is described in the description, so agents understand return values. Given the tool's complexity and the presence of sibling analysis tools, this is a complete and self-contained description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 0% (no parameter descriptions in schema), but the description adds 'repo_name: Repository to analyse.' While minimal, this clarifies the parameter's role beyond the schema's title. The parameter is self-explanatory, and the description compensates adequately for the lack of schema coverage.
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 clearly states the tool detects second-order injection patterns, describes the two-step (write then read) process, and explicitly labels it as a structural approximation. This differentiates it from sibling taint analysis tools like find_taint_flows, which handle direct flows. The verb 'Detect' and specific resource 'second-order injection patterns' provide a precise purpose.
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 gives clear context: it's an approximation, not a definitive scanner, to be used for prioritizing manual review. This implies when to use (for discovery) and when not (as sole decision). It does not explicitly name alternatives, but the sibling list provides that context. The guidance on false positives is valuable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite lacking annotations, the description explains the tool aggregates taint analysis findings and maps them to a taxonomy, with no mention of side effects or destructive actions; it is adequately transparent for a read report tool.
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 well-structured with Args and Returns sections, but could be slightly more concise; however, every sentence provides necessary context.
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?
Given the tool's complexity and lack of output schema, the description fully explains the output structure for each framework, ensuring completeness for agent selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description enumerates acceptable values for 'framework' (owasp, cwe, pci, stig) and explains the purpose of 'repo_name', adding significant meaning beyond the minimal schema (which has 0% coverage).
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 clearly states the tool generates a security findings report mapped to a compliance framework, mentioning specific frameworks (OWASP, CWE, PCI, STIG) and distinguishing it from siblings by focusing on compliance mapping rather than raw analysis.
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 purpose is clearly scoped to compliance report generation, but it does not explicitly contrast with sibling tools like find_taint_flows or blast_radius, leaving the agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full behavioral burden. It explains the return value (a dict with specific keys) and the data source (merged built-in + user-defined rules). It does not mention error conditions or permissions, but for a read-only listing tool with no parameters, this is sufficient.
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 concise (4 lines) and front-loaded, starting with the primary purpose in the first sentence. Every sentence contributes meaning: what it returns, what it shows, when it's useful, and the exact output format. No superfluous text.
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?
Given no parameters and no output schema, the description fully covers what the tool does, what it returns, and a typical use case. It leaves no significant gaps for the agent to guess.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% by default. The description adds no parameter info (none needed), but it does explain the return structure, which adds value beyond the schema. Baseline for 0 params is 4.
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 clearly states it returns the active security configuration (sources, sinks, sanitizers) and specifies 'merged built-in + user-defined rules'. This is a specific verb+resource that distinguishes it from sibling tools which focus on finding specific security issues (e.g., find_taint_flows).
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 provides a concrete use case ('useful for verifying that custom rules were loaded'), giving context for when to use. It does not explicitly exclude alternatives, but the sibling tool names (e.g., find_reachable_sinks) imply different purposes, making the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the return format (list of dicts with keys fqn, file_path, line_start) and edge cases (empty list if method not found or makes no calls). It does not discuss side effects or performance, but for a read-only lookup, this is adequate.
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 front-loaded with the purpose, then uses standard Args/Returns sections for clarity. It is concise—every sentence adds value—and uses proper formatting (backticks for code, bullet-like structure) to aid readability.
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?
Given the tool's low complexity (2 parameters, no nested objects) and the presence of an output schema (though not shown here), the description covers all necessary aspects: input format, behavior of each parameter, return structure, and edge cases. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage (only titles and types), but the description adds significant meaning: method_fqn gets a format example ('com.example.Foo.bar'), and exclude_generated gets a concrete use case (filtering Lombok/compiler-generated callees). This fully compensates for the schema's lack of descriptions.
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 clearly states 'Find all methods directly called by the given method.' It uses a specific verb ('find') and resource ('methods directly called'), distinguishing it from sibling tools like find_callers (which does the inverse) and find_implementations (which finds overrides).
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 specifies that it finds direct callees, implying when to use it (to explore a method's immediate dependencies). It does not explicitly state when not to use it or mention alternatives, but the wording 'directly called' provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It describes the return format and the nature of the data (unresolved calls). It does not mention side effects, but listing is inherently read-only. Could be improved by explicitly stating safety.
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?
Well-structured docstring with Args and Returns sections. Purpose is front-loaded. No extraneous information.
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?
Given the presence of an output schema (described in the description), the tool definition covers purpose, parameter, and return format completely. No gaps for an agent to select or invoke.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains the repo_name parameter with its effect and default value, adding meaning beyond the schema which only has a title. Schema description coverage is 0%, so description compensates fully.
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 clearly states it lists outgoing REST calls that are unresolved, using specific verb 'list' and resource 'unresolved calls'. It differentiates from siblings like list_endpoints by mentioning cross-repo or external HTTP calls.
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 explains the optional repo_name parameter and its default behavior. It does not explicitly mention when not to use or alternative tools, but the context is clear enough for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description discloses search behavior (substring match, case-insensitive) and return format (list of dicts with type, fqn, file_path). Minor gap: no mention of permissions or limitations.
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 sentences with clear docstring-style Args/Returns. Front-loaded purpose, no wasted words.
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 simple single-parameter search tool with output schema described, the description fully explains input, behavior, and return format. No missing details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema only provides 'query' as a string. Description adds critical semantics: substring match, case-insensitive, and example values. Highly compensates for 0% schema coverage.
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?
Clearly states it searches for classes or methods by name with case-insensitive substring match. Distinguishes from sibling analysis tools (e.g., find_callers, find_implementations) as a general search.
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?
Explicitly describes the search behavior and provides an example. However, does not specify when to use this tool versus alternative search tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes BFS algorithm, source annotations, sanitizer pruning, and return conditions including empty list cases. Minor omission: does not define 'dangerous sinks' explicitly, but overall transparent.
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 concise with no wasted words. It uses a clear structure: one-sentence summary, algorithm explanation, comparison to sibling, and bullet lists for arguments and return values.
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?
Given the complexity of multi-hop taint analysis, the description covers algorithm (BFS), sources, sinks, pruning, max_depth, return format, and edge cases (empty repo, no sources, no paths). The output schema is detailed in the description, making it self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description adds meaning: 'repo_name: Repository to analyse.' and 'max_depth: Maximum hop depth (default 5, capped at 10).' This compensates for the lack of schema descriptions.
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 clearly states it performs 'Multi-hop taint path analysis from annotation-based sources to dangerous sinks' and contrasts with sibling find_taint_flows, which is single-hop only. The verb 'find' and resource 'taint paths' are specific and distinguishable.
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 explicitly explains when to use this tool over the sibling find_taint_flows by noting multi-hop vs single-hop and arbitrary depth. It also mentions max_depth constraint, providing clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully explains the output format, sorting, and empty list behavior. It is transparent about what the tool does and returns.
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 concise and well-structured: purpose, output, usage hint, parameters, returns. Every sentence adds value, no fluff.
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 simple query tool with one parameter and an output schema, the description covers purpose, behavior, and return format completely. No missing context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, repo_name, is described as 'the logical name of the indexed repository', adding essential meaning beyond the schema's type-only definition. With 0% schema coverage, the description compensates fully.
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 clearly states the tool returns calls to methods not in the indexed repo, distinguishing it from siblings like find_callees or find_callers. The verb 'find_external_calls' and the explanation make the purpose unambiguous.
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 includes a useful usage hint ('what external dependencies...'), but lacks explicit direction on when not to use or specific alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![orihime MCP server](https://glama.ai/mcp/servers/srinivasan-sundaresan95/orihime/badges/card.svg)](https://glama.ai/mcp/servers/srinivasan-sundaresan95/orihime)

Score Badge

Copy to your README.md:

[![orihime MCP server](https://glama.ai/mcp/servers/srinivasan-sundaresan95/orihime/badges/score.svg)](https://glama.ai/mcp/servers/srinivasan-sundaresan95/orihime)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/srinivasan-sundaresan95/orihime'

If you have feedback or need assistance with the MCP directory API, please join our Discord server