PyEye Server

by okeefeco

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clearly distinct purpose, from dependency analysis to framework-specific finders and structural queries. Even similar-sounding tools like 'expand' and 'outline' are precisely differentiated by their descriptions (single-hop vs full skeleton). The deprecated tools are noted but do not cause confusion.
Naming Consistency4/5
Tools predominantly use underscore_case and descriptive verb-noun patterns (e.g., find_*, get_*, trace_*). However, there is some variation: single verbs like 'expand' and 'inspect' coexist with 'find_blueprints' and 'get_model_schema'. The consistency is high but not perfect, with no mixed casing.
Tool Count4/5
25 tools is on the higher side but well-scoped for a comprehensive Python code analysis server covering dependency, symbol resolution, structural queries, and framework-specific finders (Flask, Pydantic). The count feels justified given the breadth of functionality, though a slight reduction could improve coherence.
Completeness4/5
The tool set covers a wide range of analysis needs: dependency mapping, symbol resolution, structural inspection, multihop traversal, and framework-specific queries. The presence of deprecated tools (analyze_dependencies, get_call_hierarchy) indicates API transition, but the current surface is largely complete for the domain. Minor gaps exist (e.g., no tool for runtime-injected members beyond static analysis limits).
Average 4.1/5 across 25 of 25 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 161 commits in the last 12 weeks
- Last stable release on March 11, 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 carries full burden for behavioral disclosure. It does not state whether the tool is read-only, what it returns, any side effects, or required permissions. The description only explains the scope parameter, leaving behavior largely implicit.
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, starting with the purpose, followed by a well-structured Args block. Each sentence adds value without redundancy. It is appropriately sized for a single-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema (not shown), the description covers the main usage. However, it lacks information on edge cases, error conditions, or prerequisites. For a simple find tool, the completeness is adequate but not exceptional.
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 parameter schema has 0% description coverage, but the description adds significant meaning by explaining the scope options (main, all, namespace:name) and default behavior. This goes beyond what the schema provides, compensating for the lack of schema-level descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find Flask CLI commands', which is a specific verb and resource. It distinguishes from sibling tools like find_blueprints or find_routes by focusing on CLI commands. However, it does not explicitly contrast with siblings, so it's a 4 rather than 5.
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 scope parameter with three options, providing some guidance on search granularity. However, it does not specify when to use this tool versus alternatives (e.g., when to use find_cli_commands vs. other find tools), nor does it mention any prerequisites or exclusions.
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 exist, so the description carries the behavioral burden. It implies a read-only operation (tracing) without declaring side effects, permissions, or rate limits. This is neutral but insufficient to score higher; no contradictions.
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 relatively short and structured with an Args block. However, the header 'Trace the inheritance hierarchy of a Pydantic model.' is somewhat redundant with the tool's name, and the docstring format could be tighter.
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 presence of an output schema (not shown but signaled), the description adequately covers the input parameters and basic purpose. It does not explain return value details, but the output schema likely handles that. For a single-purpose tool, this is 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?
Schema coverage is 0%, meaning the description must compensate. It explains both parameters, especially detailing the scope values ('main', 'all', 'namespace:name'). However, it omits that scope can also be an array of strings, which limits completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Trace' and identifies the resource 'inheritance hierarchy of a Pydantic model', making the purpose clear. While it distinguishes from siblings like 'trace' (more generic) and 'get_model_schema' (schema vs hierarchy), it does not explicitly highlight the uniqueness, so it falls short of a 5.
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. The description only explains the parameters, not the context or when-not-to-use. Sibling tools like 'find_models' or 'trace' are not mentioned, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It does not mention that the tool is read-only, safe, or what happens on errors/empty results. Only notes scope filtering 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 concise, front-loads the main purpose, and presents parameter details in a clean list format without 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?
Given the tool has only one parameter with an output schema, the description sufficiently covers the parameter. However, it could be slightly more complete by indicating the tool is read-only or providing a brief note on return type, but that is mitigated by the output schema.
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 input schema has 0% description coverage, so the description must compensate. It adds significant meaning by listing the three possible values for 'scope' with explanations, beyond what the schema provides (only type and default).
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 Flask view functions and classes', using a specific verb and resource. This distinct purpose differentiates it from sibling tools like find_routes, find_blueprints, etc.
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 vs alternatives. It only explains the scope parameter options, but no context on when to choose this over siblings like find_routes or find_blueprints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It only explains the function and parameters, with no mention of side effects, error conditions, performance, or authorization needs. This leaves significant gaps for safe invocation.
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 reasonably concise, using an Args section with bullet points for scope options. Every sentence contributes information, though it could be slightly tighter. Structurally clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It adequately covers inputs. However, it lacks any mention of errors or expected behavior when the model is not found, leaving some contextual gaps.
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 input schema has 0% description coverage, but the description compensates by providing clear semantics for both parameters: model_name as 'Name of the model' and scope with enumerated options and defaults. This adds value beyond the bare schema titles.
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 'Get' and the resource 'schema for a specific Pydantic model', making the purpose unmistakable. It distinguishes itself from siblings like 'find_models' which locate models rather than retrieving their schema.
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 scope parameter options but does not explicitly state when to use this tool versus alternatives like 'find_models' or 'trace_model_inheritance'. Usage is implied but lacks explicit guidance on exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the operation is read-only, requires authentication, or has any side effects. As a find tool, it is likely safe, but this is not stated.
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 and a short argument list. No extra words, well-structured with an 'Args' section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need not be explained, but the description lacks behavioral context (e.g., read-only hint) and any prerequisites, which would improve completeness given no annotations.
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 input schema has 0% description coverage, but the description adds significant meaning by explaining the scope parameter's default and enumerated values ('main', 'all', 'namespace:name'), guiding the agent effectively.
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 computed fields, specifying 'properties' and 'computed_field decorator', which distinguishes it from sibling tools like find_models and find_field_validators.
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 scope parameter options and defaults, giving clear usage context, but does not explicitly state when not to use the tool or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose that the tool is read-only, safe, or has any behavioral traits. The description only states what it finds, not implications for the agent.
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: one sentence for purpose, followed by a well-structured list for the parameter. No redundant information, and the critical part (purpose) 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?
Given the output schema exists, return values are covered. The description adequately explains the single parameter. Lacking a brief note on what the output contains (e.g., extension names) but is otherwise complete for the tool's simplicity.
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 elaborates on the 'scope' parameter with three explicit values and meanings, providing context beyond the schema which only defines type and default. This fully compensates for the 0% schema description 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 'Find Flask extensions in use' – a specific verb and resource. It distinguishes from sibling tools like find_models or find_routes by targeting extensions specifically.
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 vs alternatives like analyze_dependencies or find_references. The description does not state when to use or avoid this tool, nor does it mention 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?
With no annotations provided, the description must fully convey behavioral traits. It explains the configuration action and mentions saving to .pyeye.json, but does not disclose side effects, idempotency, or permissions. This adds some transparency but not comprehensive.
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: a single sentence stating purpose followed by a well-structured parameter list. No wasted words, front-loaded with the main action.
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 7 parameters and an output schema (mentioned but not shown), the description adequately covers the configuration purpose and parameter meanings. It lacks usage context or behavior details but is sufficient for a configuration 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 input schema has 7 parameters with 0% description coverage. The description includes an 'Args' section that provides brief but meaningful descriptions for each parameter (e.g., 'packages: List of package paths to include'), adding semantic value beyond the schema titles.
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 verb+resource: 'Configure additional packages, namespaces, and standalone scripts for analysis.' It distinctly describes what the tool does and differentiates it from sibling tools like 'analyze_dependencies'.
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 vs alternatives. The description implies it is for configuration before analysis, but does not mention prerequisites, limitations, or comparison with similar 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?
No annotations are provided, so the description must disclose behavioral traits. It reveals the tool is legacy and will be removed, but it does not mention permissions, destructive potential, rate limits, or return format. While the tool appears read-only, this is not explicitly stated, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy due to the deprecation notice and file reference, which takes space away from the core purpose. It is structured with a brief intro followed by an Args list, but the migration details could be condensed or moved to a notes section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of call graph traversal and the lack of schema descriptions, the description explains what the tool does and its parameters, but it omits details about the output format, error handling, or any limitations beyond 'beyond default limit'. The presence of an output schema mitigates this slightly, but more context would help.
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, the 'Args' section explains each parameter's role: function_name as the function to trace, file as an optional search scope, and project_path as the root path. This adds meaningful context beyond the raw schema, though the description could clarify that function_name is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool traces function callers and callees through the codebase, and it distinguishes itself from siblings like `inspect` and `expand` by offering full call graph traversal beyond the default limit. However, the immediate deprecation notice and reference to replacements muddles the primary purpose slightly.
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 states that the tool is deprecated, replaced by `inspect(handle).edge_counts.callers` and `expand(handle, edge="callers")`, and advises preferring `lookup()` for general use. This provides clear when-to-use and when-not-to-use guidance, along with named alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It does not disclose what happens if no handlers are found, the return format, or any side effects. More behavioral context is needed.
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 at about 50 words, front-loaded with the purpose, and uses a bulleted list for scope options. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values need not be detailed. However, the description could mention the output structure or typical results. It is minimally adequate for a simple search 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 input schema has 0% coverage, but the description adds meaning by listing possible scope values and their meanings, going beyond the schema's type definition. This compensates partially for the schema gap.
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 error handler functions. The verb 'Find' and resource 'error handlers' are specific and distinct from sibling tools like 'find_blueprints' or 'find_cli_commands'.
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 scope parameter options ('main', 'all', 'namespace:name') with clear defaults, guiding usage. However, it does not explicitly state when to choose this tool over other 'find' siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states it 'finds' models, providing no behavioral details like side effects, permissions, or whether it makes external calls.
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 primary purpose, then concisely documents the parameter in a structured format (Args:) without any superfluous information.
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 tool has only one optional parameter and an output schema exists, so the description adequately covers the parameter and context. It could mention the output type or that it searches the project, but it's sufficient.
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 fully compensates by detailing the scope parameter with its valid values ('main', 'all', 'namespace:name') and defaults, which is critical for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Find all Pydantic models in the project' which clearly identifies the tool's action and target resource. It distinguishes itself from sibling tools like find_blueprints or find_routes.
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 scope parameter options but lacks explicit guidance on when to use this tool versus alternatives 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.
Behavior2/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 does not disclose behavioral traits such as read-only nature, side effects, or performance implications. For a find operation, it is likely safe, but this is not stated.
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: one sentence for purpose followed by a bullet list for parameter details. No superfluous content, and the main purpose 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?
The description covers the input parameter well and, since an output schema exists, return values need not be explained. However, it lacks details on error conditions or prerequisites, which would improve completeness.
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?
Despite 0% schema coverage, the description thoroughly explains the 'scope' parameter with enumerated options (main, all, namespace:name) and their meanings, adding significant value beyond the schema definition.
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 Flask routes in the project, using a specific verb and resource. This distinguishes it from sibling tools like find_views or find_blueprints, which target different entities.
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 provides scope options but does not explicitly state when to use this tool over alternatives (e.g., find_views). Usage context is implied but not directive.
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 describes the tool's operation (finding config) but does not disclose behavioral traits such as read-only nature, potential side effects, 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?
The description is extremely concise, with the purpose stated in the first sentence followed by compact parameter documentation. No extraneous information is present.
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, the output schema existence, and the detailed parameter explanation, the description covers essential usage details. Minor gaps like behavior on invalid scope are acceptable for a search 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 input schema has no descriptions (0% coverage), but the description adds significant meaning by enumerating valid scope values and their semantics, which the schema does not provide.
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 Flask configuration files and app.config usage, making the verb and resource explicit. It distinguishes from sibling tools like find_model_config, which likely handles model-specific config.
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 details scope parameter options but lacks explicit when-to-use or when-not-to-use guidance compared to similar tools like find_model_config. The inferred usage is adequate but not explicitly contrasted.
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 of behavioral disclosure. It details the scope parameter but omits side effects, return format, permissions, or rate limits. The transparency is adequate for a read-only tool but lacks richness.
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 front-loaded with the main purpose, followed by a well-structured bullet list for the parameter. Every sentence adds necessary information without 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 (1 optional parameter) and the existence of an output schema, the description covers the essential usage. It lacks detail on output format or additional behavioral constraints, but these are partially handled by the output schema.
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%, yet the description adds significant value by explaining the three scope options with examples. This compensates for the missing schema descriptions, making parameter usage clear.
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 'Find all model configurations,' which clearly identifies the action and resource. It differentiates from siblings like 'find_models' and 'find_config' by specificity.
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 scope parameter with options, providing clear context for usage. However, it does not contrast with alternative tools (e.g., when to use find_config instead), leaving usage guidance incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey all behavioral traits. It does not mention side effects, read-only nature, or what the tool returns. The description focuses only on parameter semantics, leaving behavioral aspects unclear.
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 reasonably concise with a short summary followed by a structured parameter list. However, it could be more front-loaded by stating the main purpose before the parameter details.
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 that an output schema exists, the description need not explain return values. The single parameter is well-documented, but the lack of any behavioral or safety context (e.g., read-only, no side effects) leaves minor 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?
With 0% schema description coverage, the description fully compensates by explaining the scope parameter in detail, including its default value and three possible values with meanings. This adds significant value beyond the schema structure.
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 finds Flask templates and render_template calls, with a specific verb 'find' and resource. It is distinct from sibling tools like find_blueprints or find_routes.
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 detailed explanation of the scope parameter with three clear options, helping the agent decide when to use different scopes. However, it does not explicitly compare with alternative tools or state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/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 of behavioral disclosure. It does not mention whether the tool is read-only, has authorization requirements, or any side effects, leaving transparency lacking.
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 brief and front-loaded with the main purpose. The parameter documentation is presented in a concise docstring format with no wasted words.
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 (one parameter) and the presence of an output schema, the description covers the essential information. It does not mention limitations or side effects, 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?
With 0% schema description coverage, the description adds significant meaning to the scope parameter by explaining its possible values and default behavior, going beyond the schema which only defines the type.
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 finds all Pydantic validators in the project, using a specific verb and resource. This distinguishes it from siblings like find_field_validators which may be more specific.
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 documents the scope parameter with its default and options, providing clear context for usage. However, it does not explicitly mention when to use this tool versus alternatives like find_field_validators.
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 provided; description mentions deprecation and replacement but lacks explicit statement about read-only nature or side effects. The tool appears read-only but not confirmed.
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 but the first sentence includes an unclear phrase 'Semantic analysis grep can't do'. Deprecation notice is front-loaded appropriately, and args are listed clearly.
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?
Has output schema so return info not needed. Parameters explained. Lacks prerequisites or error info, but sufficient for a deprecated tool with alternatives given.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0%, but the description's Args section adds basic meaning with examples for module_path and possible values for scope. However, it doesn't explain defaults or scope list format in 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 tool maps module dependencies and detects circular imports, and distinguishes from siblings like trace and lookup by noting this tool is deprecated and replaced.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly recommends alternatives for general use (lookup) and future use (trace), and specifies when to use this tool for targeted circular dependency queries.
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 fully explains the return behavior (success, ambiguous, not found) and the meaning of the result. It does not mention any side effects, which is acceptable for a resolution tool, but could be more explicit about 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?
The description is well-structured with a brief introductory sentence followed by parameter details and return value explanation. It is slightly long but not verbose; 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 accepted inputs, return formats, and parameter details. It omits preconditions like requiring a Python project or environment, and does not explain the output schema fields in detail. However, given the output schema exists, the description is adequately complete.
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 thoroughly by detailing the identifier forms (bare name, FQN, re-exported, file:line, file only) and explaining the project_path default. This adds significant meaning beyond the schema's type definitions.
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 it resolves any identifier form to a canonical Handle, listing specific accepted forms. This clearly distinguishes it from sibling tools like 'find_references' or 'resolve_at' by focusing on identifier resolution to definition-site handle.
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 through the listed identifier forms, but lacks explicit guidance on when to use this tool versus alternatives (e.g., 'resolve_at') and does not specify 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?
No annotations are provided, so the description carries the full burden. It implies a read-only search operation but does not explicitly state non-destructive behavior or other traits like required permissions.
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 single sentence plus a clear list for the parameter options. Every part adds value, and the structure is easily scannable.
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 has only one optional parameter and an output schema exists, the description adequately covers purpose and parameter behavior without needing to describe return values.
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 value by explaining the scope parameter's possible values and their meanings, compensating for the lack of schema-level documentation.
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 the specific verb 'Find' and resource 'all Flask blueprints in the project', clearly distinguishing it from sibling tools that target different aspects (e.g., find_routes, find_models).
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 explicit guidance on the scope parameter with three well-defined options (main, all, namespace:name), but does not explicitly state when not to use this tool or mention 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?
With no annotations provided, the description carries the burden of behavioral disclosure. It explains the behavior of the 'scope' parameter, but does not mention any side effects, permissions, rate limits, or output structure beyond what is implied by the tool name. The presence of an output schema partially mitigates the need to describe return values.
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, consisting of three lines including the 'Args' header. It uses a bullet-point list for the parameter options, making it easy to scan. Every sentence serves a purpose with no superfluous 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?
For a tool with one well-documented parameter and an output schema (not shown), the description is largely complete. It could be improved by briefly noting what the output contains or mentioning any constraints, but the current level is adequate for the tool's simplicity.
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 schema coverage is 0%, so the description must compensate. It fully explains the single 'scope' parameter, including its default value and three possible values with clear meanings. This adds significant value beyond the schema, which only defines type and default.
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 'Find all field-specific validators,' which clearly states the tool's purpose. It distinguishes from sibling tools like 'find_validators' by specifying 'field-specific', making the tool's role 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 provides detailed guidance on the 'scope' parameter with three explicit options and their semantics. However, it does not explicitly compare this tool to alternatives like 'find_validators' or specify when to choose one over the other, which would strengthen this dimension.
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 describes the operation and return shape (like resolve()) but omits failure behavior, side effects, or safety assurances. Adequate but not fully 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?
Two concise paragraphs plus bullet-like argument list. Every sentence earns its place. No redundancy, well front-loaded with purpose and usage 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 output schema existence, description needn't detail return values beyond referencing resolve(). Covers all four parameters, usage context, and coordination with sibling. Complete for this 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%, so description must explain all parameters. It provides clear semantics: file path type, 1-indexed line, 0-indexed column with coercion warning, and project_path default. Adds significant value 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?
The description clearly states it resolves a (file, line, column) position to a canonical Handle, specifically for coordinates from stack traces or error reports. It distinguishes itself from the sibling 'resolve' tool by emphasizing coordinate-based input rather than name-based.
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 ('when you have coordinates from a stack trace, error report, or pasted excerpt rather than a name'). Links to sibling 'resolve' for return shape. Lacks explicit when-not-to-use, but context is clear.
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 provided, the description fully carries the transparency burden. It explicitly states the tool is cheap, returns no source content or exhaustive enumerations, and details the return structure including universal and kind-dependent fields. There is no ambiguity about behavior or safety.
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 opening sentence, followed by a bulleted list of return fields. While it is somewhat lengthy, every sentence adds value and the bullet format improves readability for an AI agent parsing the return types.
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 and the complexity of the tool with kind-dependent fields, the description is highly complete. It covers all necessary aspects: purpose, parameter details, return structure with examples for each kind, and behavioral notes (cheap, no source content). No major gaps are present.
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?
Although schema description coverage is 0%, the description adds meaningful context for both parameters: handle is described as a 'Canonical Python dotted-name string (from resolve/resolve_at)' and project_path as 'Project root path (default: current directory)'. 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 inspects a canonical handle and returns a structural Node, explicitly framing it as the 'what is this?' operation. It distinguishes from siblings by referencing resolve/resolve_at for obtaining handles and noting this tool is cheap by default without source content or exhaustive enumerations.
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 clear context on when to use: it is cheap, returns kind-dependent fields, and notes that edge counts and highlights come in later phases. It implicitly contrasts with more expensive operations but does not explicitly name alternatives like expand or outline for when more detail is needed.
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?
Despite no annotations, the description comprehensively details behavioral traits for each edge: static-surface ceilings, response shape, error handling (never raises), and exact conditions for unsupported branches. It discloses limitations like runtime-injected members and dynamic imports.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very lengthy and could be more concise. While it is well-structured with bullet points and code blocks, the verbosity may hinder quick comprehension. However, it front-loads the one-sentence summary.
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 many sibling tools (22 listed), the description covers all necessary context: when to use, inputs, outputs for each branch, edge-specific details, behavioral ceilings, and relationship to deprecated tools. It is exceptionally 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 input schema has 0% description coverage, but the description adds meaning by explaining that handle is a canonical dotted name, edge is a specific outbound edge with enumerated possibilities, and project_path defaults to current directory. Though not all parameters are explicitly described in a structured way, the context provided is sufficient.
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 expands one outbound edge from a canonical handle, lists all supported edges with examples, and distinguishes from sibling tools like resolve(), inspect(), and trace(). It also mentions superseding deprecated tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs to use resolve()/inspect() first, then expand(). Explains when to use trace() for transitive closure. Lists unsupported edges and why they are unsupported, providing clear guidance on when not to use this tool.
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?
Despite no annotations, the description discloses key behaviors: static-surface ceiling (no runtime members), absence contracts for children truncation, truncation reasons, and error handling (never raises, minimal tree on unresolvable handle).
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 lengthy but well-structured with clear sections (purpose, returns, usage, behavioral notes, args). Some redundancy could be trimmed, but it remains organized and front-loaded with core purpose.
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 (4 params, output schema, behavioral nuances, sibling variety), the description covers all necessary aspects: parameters, return structure, edge cases, contracts, and ordering. An output schema exists, reducing the burden, but the description adds thorough 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?
With 0% schema coverage, the description provides thorough explanations for all four parameters, including defaults, semantics of max_depth and max_nodes, and the role of project_path. Adds significant value 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 the tool returns a structural skeleton (names, kinds, signatures, line spans) and distinguishes it from siblings by positioning it as the single-call answer to 'show me the structure of this scope.'
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 advises using resolve() or inspect() first to obtain a canonical handle, then call outline(). Provides clear context but lacks explicit when-not-to-use or alternatives for structural inspection.
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 key behaviors: deduping by canonical handle, no silent drops (unsupported edges reported), edges not deduped across kinds, cycle guarantee (never re-expands visited nodes), truncation triggers (max_depth/max_nodes), and that it never raises. This transparency is exceptional.
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 fairly long but well-organized into logical sections: summary, composition context, response shape, and parameter details. Every sentence serves a purpose, explaining behavior or constraints. A minor reduction in redundancy could improve conciseness, but it's already efficient for the 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?
Given the tool has 6 parameters, an output schema, and no annotations, the description covers all critical aspects: input semantics, output format with fields (nodes, edges, truncated, unsupported_edges), edge behaviors, termination guarantees, and error handling (never raises). The output schema exists but the description adds necessary context beyond the raw schema.
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%, so the description must carry the entire parameter documentation burden. It does so thoroughly: start accepts a single handle or list; follow lists edge names; project_path defaults to current dir; max_depth and max_nodes have defaults; stop_when is a StopPredicate with examples (exclude_external, module_pattern, exclude_tests). This greatly enriches 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 opens with a clear statement: 'Python: Bounded multi-hop BFS traversal — returns a typed Subgraph.' It then explains its role as a composition primitive distinct from sibling tools like expand and resolve. The verb 'traverses' and resource 'Subgraph' are specific, making 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 advises using resolve()/inspect() first to get canonical handles, then trace() for structural exploration. It mentions the common callees case and describes stop_when for excluding external packages. While it doesn't explicitly state when not to use, the context is sufficient for an AI agent to decide.
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?
Despite no annotations, the description fully discloses behavioral traits: it understands inheritance, returns error with matches list if ambiguous, and explains precedence of coordinates over symbol name. It also details output fields and defaults. No contradictions.
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 summary, usage guidance, conventions, and parameter details. It is front-loaded with key information. However, it is somewhat lengthy and could be slightly trimmed without losing clarity, but it remains effective.
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 8 parameters, no annotations, and complex features (two conventions, inheritance, error handling), the description covers all necessary aspects. It also has an output schema (not shown) so return values are handled. The description 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 description adds significant meaning beyond the schema, which has 0% coverage. It explains each parameter, including indexing conventions (line 1-indexed, column 0-indexed), the interaction between coordinate parameters and symbol_name, and the valid values for fields. This is essential for correct usage.
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 usages of a symbol in Python, understands inheritance, and distinguishes itself from grep. It also mentions an alternative tool (lookup()) and explains two calling conventions, making the purpose very specific.
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 advises to prefer lookup() for general use, explains when to use coordinates vs symbol name, and warns that symbol name can fail if ambiguous. This gives clear guidance on when to use this tool vs alternatives.
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:

[![pyeye-mcp MCP server](https://glama.ai/mcp/servers/okeefeco/pyeye-mcp/badges/card.svg)](https://glama.ai/mcp/servers/okeefeco/pyeye-mcp)

Score Badge

Copy to your README.md:

[![pyeye-mcp MCP server](https://glama.ai/mcp/servers/okeefeco/pyeye-mcp/badges/score.svg)](https://glama.ai/mcp/servers/okeefeco/pyeye-mcp)

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/okeefeco/pyeye-mcp'

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