Fixie MCP Server
Server Details
Parse FIX messages and help agents create Fixie initiators.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- onikora/mcp-registry
- GitHub Stars
- 0
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 3.6/5 across 7 of 7 tools scored. Lowest: 3/5.
Each tool has a clear and distinct purpose: generating initiator source, generating runtime config, retrieving recipes or templates, validating specs, and parsing FIX messages (single vs multiple). No overlap.
All tool names follow a consistent verb_noun pattern in snake_case, such as generate_initiator_source, parse_fix_message, and validate_initiator_spec.
With 7 tools, the set is well-scoped for the Fixie initiator domain—covering generation, configuration, validation, and message parsing—without being too sparse or overwhelming.
The tool surface fully covers the intended workflow: generating initiator code and config, retrieving supporting information, validating specs, and parsing FIX messages in single or batch mode. No obvious gaps.
Available Tools
7 toolsgenerate_initiator_sourceGenerate Fixie Initiator SourceBInspect
Generates generic Java source for a managed or standalone Fixie initiator.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | managed or standalone | |
| use_case | No | market_data, order_entry, or quote_request | |
| class_name | No | Java class name | |
| package_name | No | Java package name |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It does not disclose whether the tool is read-only or destructive, what side effects occur, or whether it returns code or writes files. This is a significant gap for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no fluff. However, it could be slightly more informative while remaining concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 parameters (all optional), no output schema, and no annotations, the description is minimal. It provides the core purpose but lacks details about output format or behavior, which would help for a generation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. The description adds no further meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Generates'), the resource ('generic Java source'), and the context ('managed or standalone Fixie initiator'). It effectively distinguishes from sibling tools like generate_runtime_config or get_initiator_recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool compared to siblings such as get_initiator_recipe or validate_initiator_spec. The description lacks context about prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_runtime_configGenerate Fixie Runtime ConfigBInspect
Generates a runtime configuration entry for a Fixie initiator.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Acceptor host | |
| name | No | Runtime entry name | |
| port | No | Acceptor port | |
| use_case | No | market_data, order_entry, or quote_request | |
| class_name | No | Fully qualified Java class name | |
| senderCompId | No | Initiator SenderCompID | |
| targetCompId | No | Acceptor TargetCompID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It only states 'Generates a runtime configuration entry' with no disclosure of side effects, required permissions, or behavioral traits like whether it overwrites existing entries. This is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and concise. Every word adds value; there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about the output (no output schema) and what a runtime configuration entry entails. With 7 optional parameters and no annotations, more guidance on how parameters interact would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (all 7 parameters have descriptions). The description adds no additional meaning beyond the schema. Baseline of 3 is appropriate since the schema already documents each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'generates' and resource 'runtime configuration entry' with context 'for a Fixie initiator'. It distinguishes from sibling tools like 'get_runtime_config_template' (retrieves a template) and 'generate_initiator_source' (generates source code). However, it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. There are no conditions, prerequisites, or exclusions mentioned. Sibling tools exist (e.g., get_runtime_config_template) but the description offers no comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_initiator_recipeGet Fixie Initiator RecipeAInspect
Returns the recommended Fixie initiator pattern for market_data, order_entry, or quote_request.
| Name | Required | Description | Default |
|---|---|---|---|
| style | No | managed or standalone; managed is recommended | |
| use_case | No | market_data, order_entry, or quote_request | |
| fix_version | No | FIX version, defaults to FIX.4.4 |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It adequately describes the tool as a simple retrieval with no side effects, but does not detail the nature of the returned pattern, authentication requirements, or any rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and scope. No extraneous information. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description hints at the return value ('pattern') but does not specify its format. However, for a simple query tool with no required parameters, it is sufficiently complete for an agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with all three parameters described (style, use_case, fix_version). The description adds no additional meaning beyond the schema, meeting the baseline for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool returns a 'recommended Fixie initiator pattern' and lists the specific use cases (market_data, order_entry, quote_request). This distinguishes it from siblings like generate_initiator_source which generates code, and get_runtime_config_template which deals with configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage context is clearly defined by listing the three specific use cases. However, no explicit exclusions or alternatives are mentioned, leaving some ambiguity about when not to use this tool versus its siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_runtime_config_templateGet Fixie Runtime Config TemplateBInspect
Returns a JSON runtime configuration template for a Fixie initiator.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Acceptor host | |
| port | No | Acceptor port | |
| use_case | No | market_data, order_entry, or quote_request | |
| senderCompId | No | Initiator SenderCompID | |
| targetCompId | No | Acceptor TargetCompID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'returns a template' but does not disclose whether it is a read-only operation, if it requires any prior setup, or if it modifies any state. Critical behavioral traits are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal for a tool with 5 parameters. It could benefit from more context without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema and no annotations. The description does not explain what a Fixie initiator is, what the template is used for, or how the parameters influence the output. Given the complexity of 5 optional parameters, the description is insufficient for an agent to fully understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 each parameter. The description adds no additional meaning beyond the schema (e.g., how parameters relate to the template output). Hence baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a JSON runtime configuration template for a Fixie initiator, which is a specific verb (returns), resource (template), and domain (Fixie initiator). This distinguishes it from sibling tools like generate_runtime_config (which likely produces a concrete config) and get_initiator_recipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as generate_runtime_config or get_initiator_recipe. Does not mention prerequisites, conditions, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_fix_messageParse FIX MessageAInspect
Use this tool whenever you see one raw FIX message string, typically starting with 8=FIX. The input may use pipe (|) or SOH separators. By default it returns only the human-readable hierarchical output. Set type=tags to return only the hierarchical FIX field/tag view.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Optional override for single-message parsing. Omit it to return the default human-readable output. Use "tags" to return the hierarchical FIX field/tag output only. | |
| raw_message | Yes | The raw FIX message. The tool accepts either pipe separators or SOH separators. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds input format acceptance (pipe or SOH separators) and output options (default human-readable vs. tags). Does not cover error handling or performance implications, but is adequate for a parsing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy; the key use case is front-loaded, and every sentence adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 parameters, no output schema), description explains input formats and output types sufficiently. Lacks error handling notes but is largely complete for typical usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds value by explaining the effect of the 'type' parameter (returns hierarchical tag view) and confirming input format flexibility beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'parse' and resource 'FIX message', and distinguishes from the sibling tool 'parse_fix_messages' by specifying 'one raw FIX message string'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use the tool ('whenever you see one raw FIX message string'), describes input format and optional type parameter. Does not explicitly mention when not to use or alternatives to siblings, but the sibling name implies handling multiple messages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
parse_fix_messagesParse FIX MessagesAInspect
Use this tool whenever you see multiple raw FIX messages that need to be parsed in order. Each message typically starts with 8=FIX and may use pipe (|) or SOH separators. Returns ordered Onikora UFO, FFO, and optional sequence output.
| Name | Required | Description | Default |
|---|---|---|---|
| outputs | No | Optional outputs to include. Defaults to ["ufo", "ffo"]. "ufo" is the human-readable hierarchical output. "ffo" is the hierarchical FIX field/tag output. "sequence" is the ordered sequence-row view. | |
| messages | Yes | Ordered list of raw FIX messages. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes output types (UFO, FFO, sequence) and separator formats, but does not disclose error behavior, malformed message handling, or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with usage guidance and key details. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema, but description only vaguely mentions output types (UFO, FFO, sequence) without explaining their structure or format. No mention of return values for erroneous input, which is important for a parsing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and description adds minimal meaning beyond schema. It reiterates that 'messages' is an ordered list and 'outputs' defaults to ['ufo','ffo'], which is already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('parse') and resource ('multiple raw FIX messages') with scope ('in order'). Distinct from sibling 'parse_fix_message' which handles a single message.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'whenever you see multiple raw FIX messages'. Does not explicitly state when not to use or mention alternatives, but the sibling tool name 'parse_fix_message' implies the distinction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
validate_initiator_specValidate Fixie Initiator SpecAInspect
Checks whether the initiator request has enough information to generate useful Fixie code.
| Name | Required | Description | Default |
|---|---|---|---|
| host | No | Acceptor host | |
| port | No | Acceptor port | |
| use_case | No | market_data, order_entry, or quote_request | |
| senderCompId | No | Initiator SenderCompID | |
| targetCompId | No | Acceptor TargetCompID |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full burden. It indicates a non-destructive read operation (checks information), but does not disclose details such as whether it requires network calls, permissions, or the format of the response. The phrase 'useful Fixie code' is vague regarding the behavior's nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded with the tool's purpose. Every word contributes meaning, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about the return value or output format. Without an output schema, the agent cannot know what the tool returns (e.g., boolean, list of issues). This is a significant gap for a validation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with each parameter having a clear description (e.g., 'Acceptor host'). The tool description adds no additional meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool 'checks whether the initiator request has enough information to generate useful Fixie code', which is a specific verb and resource. It distinguishes from sibling tools like 'generate_initiator_source' and 'generate_runtime_config' by focusing on validation instead of generation or configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use as a validation step before code generation, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or conditions. The context is clear but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!