Skip to main content
Glama

athena_submit_feedback

Submit feedback after resolving an athenahealth issue to help the knowledge base learn from the experience.

Instructions

Submit feedback about an athenahealth interaction outcome. Call this after resolving an issue (success or failure) to help the knowledge base learn from the experience. Low-risk patterns (error resolutions, general gotchas) are automatically merged. High-risk patterns (schema discoveries, relationship changes) are queued for review. This is how the extension gets smarter over time.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional target identifier for the discovery, e.g. "DOCUMENT.STATUS", "APPOINTMENT.SCHEDULINGPROVIDERID", "PATIENTCASE workflow". Helps maintainers find the affected KB entry quickly.
contextYesWhat the user was trying to accomplish (e.g., "joining PATIENT to CHART for a demographics report").
outcomeYesWhether the interaction was ultimately resolved successfully.
categoryNoOptional structured category for the discovery. Providing this skips the keyword-classification step and routes the feedback faster. Use "identity_pattern" for PATIENT/CHART/identity, "schema_correction" for column/view behavior differences, "join_path" for incorrect join columns, "enum_value" for missing or new enum values.
sessionIdNoOptional. The sessionId returned by athena_command_start, if this feedback is being submitted as part of a slash-command interaction.
toolsUsedYesWhich MCP tools were called during this interaction (e.g., ["athena_explain_join", "athena_diagnose_error"]).
resolutionNoWhat worked (if success) or what was attempted (if failure). Be specific about the fix.
learnedPatternNoA new pattern, gotcha, or insight discovered during the interaction that other developers would benefit from knowing. This is the most important field — capture what was surprising or non-obvious.
errorEncounteredNoThe error message that was encountered, if any.
Behavior4/5

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

With no annotations, the description carries the full burden. It discloses that low-risk patterns are automatically merged and high-risk patterns are queued for review—important behavioral traits. No destructive actions are mentioned, and no contradictions exist.

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 concise—only 4 sentences—yet conveys the purpose, usage timing, and behavioral details. It is front-loaded and every sentence adds value.

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 has 9 parameters (3 required) and no output schema, the description covers purpose, when to use, and behavioral traits well. It omits return value details, but this is acceptable for a feedback submission tool.

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?

The input schema has 100% coverage with detailed descriptions for all 9 parameters. The tool description does not add significant extra meaning beyond what the schema already provides, so a baseline of 3 is appropriate.

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: submit feedback about athenahealth interaction outcomes to help the knowledge base learn. It uses a specific verb 'submit' and resource 'feedback', and distinguishes from siblings like athena_report_outcome by describing the automatic merging of low-risk patterns and queuing of high-risk patterns.

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 explicitly says to call this after resolving an issue (success or failure), which is clear guidance. It doesn't explicitly state when not to use it or name alternatives, but the context is well implied.

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/nous-ehr/claude_pallas_extension'

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