Skip to main content
Glama
Sign In
PyEye Server

PyEye Server

by okeefeco
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

find_flask_views

Locate all Flask view functions and classes across the main project or configured namespaces to map routes and understand application structure.

Instructions

Find all Flask view functions and classes.

Args: scope: Search scope (default: this tool's scope_defaults entry in the project config, else scope_defaults.global, else "main"): - "main": Only the main project (default for plugins) - "all": Include configured namespaces - "namespace:name": Specific namespace

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "find_flask_views"
  }
}

Input Schema

NameRequiredDescriptionDefault
scopeNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A3.5/5.0
Behavior3/5

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

No annotations are supplied, so the description carries the burden alone. It usefully discloses the default-resolution chain (tool config entry, then scope_defaults.global, then "main"), which is non-obvious behavior, but says nothing about what is returned or whether results are cached/limited. Since an output schema exists, the return-value gap is less costly.

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 purpose sentence is front-loaded and the scope documentation is organized as a compact bulleted enumeration. The nested default-resolution sentence is wordy but every clause conveys a real fallback rule.

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?

Output schema and single optional param keep the call surface small, and the scope semantics are fully covered. The missing piece is how "views" differs from Flask routes and blueprints among 20+ siblings, which is the one thing an agent actually needs to route 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?

Schema description coverage is 0% and the schema is a bare anyOf of string/array/null, so the description must compensate. It does so well, enumerating the meaning of "main", "all", and the "namespace:name" form and explaining the default fallback chain.

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?

"Find all Flask view functions and classes" gives a specific verb and resource, and the scope values narrow the target. It does not, however, distinguish itself from the close sibling find_flask_routes, which an agent may consider interchangeable.

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 argument's defaults and valid values, which implies usage context (main project vs namespaces). It never states when to pick this over find_flask_routes or find_flask_blueprints, so the sibling-selection decision is left to inference.

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

Deploy Server

Other Tools