Skip to main content
Glama
atrisorb
by atrisorb

generate_architecture_insight

Produce architectural trade-offs, risks, patterns, and recommendations by analyzing project code activity. Apply filters to refine analysis and address specific questions.

Instructions

Generate an architecture insight: trade-offs, risks, patterns and recommendations inferred from the project's code activity (requires a connected code source – github, gitlab, bitbucket or azure_devops). This is the deepest and most expensive insight (it runs extended reasoning). Use for technical review of architectural direction. Runs synchronously and returns Markdown. Consumes credits, charged once on success. Call list_filter_options before using filters.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
filtersNoPer-source advanced filters, AND-combined across dimensions. Keys MUST be source ids (an unknown source id is rejected with 400). The dimension VALUES are matched leniently – call list_filter_options first to get the real selectable values for the project rather than guessing.
sourcesNoRestrict to these source ids. Unknown ids are rejected with 400.
max_eventsNoCap on events processed (1-1000, default 250).
project_idYesProject id from list_projects to generate the insight for.
lookback_daysNoDays of history to review (1-365, default 14).
focus_questionNoA specific architectural question or component to investigate (e.g. "is the billing layer coupled to providers?").
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 synchronous execution, Markdown return, credit consumption charged on success, extended reasoning, and dependency on code sources. This provides adequate behavioral context beyond basic operation.

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 four sentences, front-loaded with purpose, and contains no redundant information. Every sentence contributes essential context (cost, prerequisites, usage).

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 complexity (nested filters, multiple parameters, missing output schema and annotations), the description covers key aspects: prerequisites, synchronous nature, credit charge, and filter pre-call. It could mention that the insight is saved/listable, but overall it is complete enough for agent use.

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 100%, so baseline is 3. The description adds meaningful guidance: focus_question for specific queries, filters require list_filter_options, sources restrict to ids, and defaults for max_events and lookback_days. This adds 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 generates an architecture insight with specific content (trade-offs, risks, patterns, recommendations) and distinguishes from sibling tools by noting it's the deepest/most expensive and for technical review of architectural direction.

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 prerequisites (connected code source like github, gitlab, etc.), advises calling list_filter_options before using filters, and indicates the use case (technical review). It does not explicitly exclude other use cases, but context with siblings implies when to use.

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

Install Server

Other Tools

Latest Blog Posts

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/atrisorb/flowrelay-mcp-server'

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