Skip to main content
Glama

consult_the_council

Analyze proposals using parallel critique agents to generate comprehensive, multi-perspective evaluations with actionable recommendations.

Instructions

Analyze a proposal using hierarchical LLM critique and synthesis.

This tool runs three specialized critique agents (positive, neutral, negative) in parallel to analyze the proposal, then synthesizes their perspectives into a comprehensive analysis with recommendations.

Args: proposal: Markdown-formatted proposal outlining the salient points of the solution to be analyzed

Returns: Complete analysis including all critiques and synthesis with consensus view, recommendations, and next steps

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
proposalYes

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
critiquesYesAll critique responses (positive, neutral, negative)
synthesisYesFinal synthesis of all perspectives
original_proposalYesThe original proposal that was analyzed
processing_metadataNoMetadata about the processing (timestamps, model versions, etc.)

Implementation Reference

  • Primary MCP tool handler for 'consult_the_council', performs input validation, logging, creates CritiqueRequest, and delegates to process_proposal for core logic execution.
    @app.tool()
    async def consult_the_council(proposal: str) -> ThinkingAugmentationResult:
        """
        Analyze a proposal using hierarchical LLM critique and synthesis.
    
        This tool runs three specialized critique agents (positive, neutral, negative)
        in parallel to analyze the proposal, then synthesizes their perspectives
        into a comprehensive analysis with recommendations.
    
        Args:
            proposal: Markdown-formatted proposal outlining the salient points
                     of the solution to be analyzed
    
        Returns:
            Complete analysis including all critiques and synthesis with
            consensus view, recommendations, and next steps
        """
        try:
            logger.info("Received thinking augmentation request")
    
            # Validate input
            if not proposal.strip():
                raise ValueError("Proposal cannot be empty")
    
            if len(proposal.strip()) < 10:
                raise ValueError("Proposal must be at least 10 characters long")
    
            # Create request object and process
            request = CritiqueRequest(proposal=proposal)
            result = await process_proposal(request)
    
            logger.info("Thinking augmentation completed successfully")
            return result
    
        except ValueError as e:
            logger.error(f"Validation error: {e}")
            raise
        except Exception as e:
            logger.error(f"Error in thinking augmentation: {e}")
            raise RuntimeError(f"Failed to process proposal: {str(e)}") from e
  • Registration of the 'consult_the_council' tool using FastMCP's @app.tool() decorator.
    @app.tool()
  • Pydantic schema for the input request used internally by the tool handler (proposal: str with validation).
    class CritiqueRequest(BaseModel):
        """Request model for critique analysis."""
    
        proposal: str = Field(
            ...,
            description="Markdown-formatted proposal outlining the salient points of the "
            "solution",
            min_length=10,
        )
  • Pydantic schema defining the structured output returned by the tool, including critiques, synthesis, and metadata.
    class ThinkingAugmentationResult(BaseModel):
        """Complete result from the thinking augmentation process."""
    
        original_proposal: str = Field(
            ..., description="The original proposal that was analyzed"
        )
    
        critiques: list[CritiqueResponse] = Field(
            ...,
            description="All critique responses (positive, neutral, negative)",
            min_length=3,
            max_length=3,
        )
    
        synthesis: SynthesisResponse = Field(
            ..., description="Final synthesis of all perspectives"
        )
    
        processing_metadata: dict = Field(
            default_factory=dict,
            description="Metadata about the processing (timestamps, model versions, etc.)",
        )
  • Core helper function implementing the thinking augmentation pipeline: creates critique agents, runs parallel analyses, synthesizes results, and constructs the final output.
    async def process_proposal(request: CritiqueRequest) -> ThinkingAugmentationResult:
        """Process a proposal through the complete thinking augmentation pipeline."""
        start_time = datetime.now(UTC)
    
        try:
            logger.info("Starting thinking augmentation process")
    
            # Create agents for this processing request
            positive_agent = CritiqueAgent("positive")
            neutral_agent = CritiqueAgent("neutral")
            negative_agent = CritiqueAgent("negative")
            synthesis_agent = SynthesisAgent()
    
            # Run all critiques in parallel
            critique_tasks = [
                positive_agent.analyze_proposal(request.proposal),
                neutral_agent.analyze_proposal(request.proposal),
                negative_agent.analyze_proposal(request.proposal),
            ]
    
            logger.info("Running parallel critiques")
            critiques = await asyncio.gather(*critique_tasks)
    
            logger.info("Critiques completed, starting synthesis")
    
            # Synthesize all critiques
            synthesis = await synthesis_agent.synthesize_critiques(
                request.proposal, critiques
            )
    
            end_time = datetime.now(UTC)
            processing_time = (end_time - start_time).total_seconds()
    
            logger.info(f"Thinking augmentation completed in {processing_time:.2f} seconds")
    
            # Create final result
            result = ThinkingAugmentationResult(
                original_proposal=request.proposal,
                critiques=critiques,
                synthesis=synthesis,
                processing_metadata={
                    "start_time": start_time.isoformat(),
                    "end_time": end_time.isoformat(),
                    "processing_time_seconds": processing_time,
                    "critique_model": "gemini-2.5-flash",
                    "synthesis_model": "gemini-2.5-pro",
                    "num_critiques": len(critiques),
                },
            )
    
            return result
    
        except Exception as e:
            logger.error(f"Error in thinking augmentation process: {e}")
            raise
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 of behavioral disclosure. It effectively describes the tool's behavior: running three specialized critique agents in parallel, analyzing the proposal from positive/neutral/negative perspectives, and synthesizing results. It mentions the parallel execution pattern and multi-perspective approach, which are valuable behavioral insights beyond basic function. However, it doesn't address potential limitations like processing time, token limits, or error conditions.

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 and front-loaded with the core purpose in the first sentence. Each subsequent sentence adds specific value: explaining the three-agent architecture, describing the synthesis process, documenting the parameter, and outlining return values. There's no wasted text, and the information is presented in a logical flow from high-level purpose to implementation 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 the tool's complexity (multi-agent analysis with synthesis), no annotations, and the presence of an output schema, the description provides good coverage. It explains the analysis methodology, parameter requirements, and return content. The output schema existence means the description doesn't need to detail return structure. However, for a complex tool with no annotations, it could benefit from mentioning potential constraints or limitations.

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 compensate. It provides meaningful context for the single parameter by specifying it should be 'Markdown-formatted' and should outline 'salient points of the solution to be analyzed.' This adds valuable semantic information beyond the bare schema type. However, it doesn't provide examples or more detailed formatting requirements.

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 with specific verbs ('analyze', 'runs', 'synthesizes') and resources ('proposal', 'three specialized critique agents'). It distinguishes itself from the only sibling tool (check_system_status) by focusing on proposal analysis rather than system monitoring. The description explains the hierarchical LLM critique and synthesis process, 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 Guidelines3/5

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

The description implies usage context by stating it analyzes 'a proposal' and outlines the specific process, but provides no explicit guidance on when to use this tool versus alternatives. Since there's only one sibling tool (check_system_status) with a completely different function, the lack of comparative guidance is less critical, but no explicit when/when-not instructions are provided.

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/dogonthehorizon/elrond-mcp'

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