FA-Technician-Brain-MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_pageA | Get full page specification by page_id. Returns fields, actions, sections, navigation context. |
| get_workflowB | Get a named workflow recipe with step-by-step instructions for automation. |
| get_api_endpointC | Get API endpoint specification by entity and operation. |
| get_table_schemaB | Get database table definition with columns and relationships. |
| get_fieldB | Get field-level specification including component type, validation, and API mapping. |
| get_interaction_patternC | Get UI component interaction pattern for automation. |
| get_validation_rulesC | Get validation rules for an entity or operation. |
| get_transitionsA | Get valid status transitions from a given work order state. |
| get_persona_permissionsB | Get what a persona/role can do at a given work order state. |
| searchB | Full-text search across all data (pages, workflows, endpoints, fields, tables, etc.). |
| get_test_fixturesA | Get test fixture data for automation. Filter by entity type or retrieve a specific fixture by ID. |
| check_provenanceB | Get provenance info for a data path — shows where the data came from and when sources were last checked. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 12 tools
Each tool targets a distinctly different resource type (endpoints, tables, fields, pages, workflows, validations, transitions, permissions, fixtures, provenance, search). The purposes are largely clear and separable. Minor potential confusion exists between get_api_endpoint, get_table_schema, and get_field since all are spec-lookup tools on different entity types, but their descriptions clearly distinguish target resources.
All 12 tools follow a clean, consistent get_/[search/check] pattern. Nine use the get_ prefix, one uses search_, and one uses check_, all of which are read-only retrieval verbs that fit a coherent convention. Nouns are consistently descriptive (api_endpoint, table_schema, validation_rules, transitions, persona_permissions).
12 tools is within the well-scoped ideal range for a domain knowledge/spec server. Each tool maps to a distinct class of technical reference data that an automation agent might need. This is a slightly-close-but-appropriate count for a comprehensive technical designer/technician knowledge base.
The surface covers a broad range of queryable knowledge: specs, schemas, fields, pages, workflows, validations, transitions, permissions, search, fixtures, and provenance. Minor gaps include the absence of any mutation or comparison tooling (e.g., diff between environments) and no explicit tool for fetching environment/tenant configuration, but core lookup coverage is strong for the stated knowledge-base purpose.