Skip to main content
Glama

aegis_check_guidelines

Read-onlyIdempotent

Verify an academic paper against publisher-specific style rules, equations, and grammar with an offline pass that needs no network calls or ML models.

Instructions

Fast offline style pass: equations, grammar and per-publisher guidelines.

Runs no ML models and makes no network calls, so it finishes in seconds.
Each requested publisher is checked separately against its own guidance.

Args:
    file_path: Absolute path to the paper file (PDF/DOCX/TEX/TXT).
    venues: Comma-separated subset of IEEE,ACM,BCS,IET,ISACA,ELSEVIER, or "all".
    html_report: Save a self-contained HTML report. Default True.

Input Schema

NameRequiredDescriptionDefault
venuesNoall
file_pathYes
html_reportNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv3.3.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive and closed-world, but the description adds genuinely useful context beyond them: no ML models, no network calls, sub-second runtime, and one check per requested venue. It does not note that html_report writes a file to disk, which is the only behavioral gap.

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?

Front-loaded with a one-line purpose, followed by two short behavior sentences and a compact Args block. Every line adds something, though the Args block is somewhat redundant with a schema the caller also sees.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers file formats, venue selection, report output, offline/fast behavior for a 3-parameter tool with an output schema (so return values need no explanation). The only shortfall is the absence of guidance on when to pick this vs. a sibling checking tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description carries the burden and does so well: it gives file_path semantics (absolute path) and accepted formats (PDF/DOCX/TEX/TXT), spells out the full venue enumeration plus the "all" shorthand, and explains html_report's default. The acceptable venue list is information the schema lacks entirely.

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?

States a specific verb and resource: an offline style pass covering equations, grammar and per-publisher guidelines. An agent can tell it is about formatting/style compliance, distinct from aegis_check_citations or aegis_analyze_paper, though no sibling is named explicitly.

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?

Usage is implied by the phrase 'style pass' and the per-publisher angle, but there is no explicit when-to-use guidance, no exclusions, and no pointer to which sibling to choose when the goal is content vs. style checking.

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