Skip to main content
Glama
Aethis-ai

aethis-mcp

Official
by Aethis-ai

aethis_refine_fields

Add field-discovery guidance and re-run discovery when fields are missing, misnamed, or enum values are incomplete. Supply project ID and feedback to improve extraction.

Instructions

Add guidance to improve field discovery, then re-discover. Use when fields are missing, misnamed, or enum values are incomplete. Adds a field_extraction guidance hint and re-runs discovery.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
feedbackYesGuidance about missing or incorrect fields (e.g., 'Section 7 implies a criminal record check')
openai_keyNoRetired and refused: Aethis LLM tools use Anthropic models only.
project_idYesThe project ID
anthropic_keyNoAn Anthropic API key the user explicitly provided for this call. [sensitive — do not echo or log] Deprecated: the raw value is written verbatim to the host's session transcript. Never fill this from the environment.
anthropic_key_envNoOptional. Only honoured when it equals the env var the user configured via AETHIS_ANTHROPIC_KEY_ENV in this MCP server's config; that configured key is used automatically, so this can be omitted. Do not guess a variable name: the server refuses any name the user did not configure.
anthropic_key_keychainNomacOS keychain reference the user created for Aethis: either 'service:account' or just 'account' (service defaults to 'aethis-anthropic-key'). The server reads it via the `security` command at call time.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.22.0

TDQS

A3.6/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, covering the mutation/safety profile. The description adds that the operation appends a 'field_extraction' guidance hint and re-runs discovery, which is useful behavioral context, but it discloses no auth requirements or reversibility detail beyond that.

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?

Three short sentences with the trigger condition front-loaded. The first and third sentences overlap somewhat ('Add guidance to improve field discovery' vs 'Adds a field_extraction guidance hint and re-runs discovery'), a minor 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?

For a non-read-only, non-idempotent mutation tool with no output schema, the description conveys purpose, trigger, and the resulting side effect adequately. Remaining gaps around auth handling are covered by the well-documented key parameters in the schema.

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 description coverage is 100%, so the schema already documents all six parameters including the feedback example. The description adds no syntax or format detail for parameters beyond what the schema provides, so the baseline 3 applies.

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: adding field-discovery guidance and re-running discovery. It reads clearly and implies a distinct role from siblings like aethis_discover_fields or aethis_add_guidance, though it does not explicitly contrast itself with those tools.

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?

Provides a clear trigger condition: 'Use when fields are missing, misnamed, or enum values are incomplete.' However, it names no alternative tool or when-not condition, so routing against siblings like aethis_validate_fields 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.