Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@akyla-mcp get Apple's latest fundamentals"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Give your AI cited financial data. This is a Model Context Protocol server for the Akyla Financial Data API: as-reported US-equity fundamentals sourced straight from SEC inline-XBRL filings, plus live quotes, full financial statements, valuation comps, and a screener over ~5–8k US stocks.
Because statement values carry per-cell filing provenance (SEC accession number + XBRL fact id), the model can point at the exact 10-K/10-Q behind every number — instead of guessing.
Works in Claude Desktop, Claude Code, ChatGPT, Cursor, Codex, Cline, Zed — anything that speaks MCP.
Tool | What it does |
| Latest price + 52-week range (optionally ~1yr of daily closes) |
| Revenue, EBITDA, margins, EV/EBITDA, net debt, FCF + live quote, in one call |
| Full key-metrics table across reporting periods |
| Income / balance sheet / cash flow, as-reported, with per-cell SEC provenance |
| Footnote disclosures from dimensional XBRL (annual/quarterly) |
| Subject company + peers with valuation multiples |
| Filter ~5–8k US equities by valuation, size, growth, quality |
Related MCP server: SEC EDGAR MCP Server
Ready-made workflows over the tools:
Prompt | What it does |
| Fast fundamental read — fundamentals + quote, summarized |
| Relative valuation vs comparable companies |
| Pull a statement with SEC provenance and cite every figure |
Free tier: 1,000 calls/month, no credit card → https://app.akyla.ai/developers
claude mcp add akyla --env AKYLA_API_KEY=ak_live_xxx -- uvx akyla-mcpSettings → Developer → Edit Config, then add:
{
"mcpServers": {
"akyla": {
"command": "uvx",
"args": ["akyla-mcp"],
"env": { "AKYLA_API_KEY": "ak_live_xxx" }
}
}
}(Or install the one-click Desktop Extension — see manifest.json.)
Same shape as above in the client's MCP config:
{
"mcpServers": {
"akyla": {
"command": "uvx",
"args": ["akyla-mcp"],
"env": { "AKYLA_API_KEY": "ak_live_xxx" }
}
}
}Run the server over HTTP and add it as a connector:
AKYLA_API_KEY=ak_live_xxx uvx akyla-mcp --transport http --port 8000
# serves MCP at http://localhost:8000/mcpFor a hosted, multi-tenant deployment, each request's key is read from the
Authorization: Bearer <key> or X-Api-Key header (falling back to AKYLA_API_KEY).
See smithery.yaml and Dockerfile.
uv sync
cp .env.example .env # add your key
uv run akyla-mcp # stdio
uv run akyla-mcp --transport http # remote
# inspect with the MCP Inspector
npx @modelcontextprotocol/inspector uv run akyla-mcp"Pull Apple's latest income statement with SEC provenance and tell me FY revenue, citing the filing."
"Screen for US companies over $10B market cap with EV/EBITDA under 12, sorted by revenue growth."
Your key stays local in stdio mode — it lives in your client's own config and
is sent only to app.akyla.ai over HTTPS. It is never logged.
Hosting the remote (HTTP) server: each request should carry its own key via
Authorization: Bearer <key> or X-Api-Key. Do not set a shared AKYLA_API_KEY
on a public multi-user endpoint — anyone who can reach it would spend that key's
quota. (Smithery isolates per-user config, so its hosted deploy is fine.)
Binding: the server binds 127.0.0.1 by default. Only set HOST=0.0.0.0
inside a container or a network you control (the Dockerfile does this).
Ticker input is validated against a strict whitelist before use.
Found a security issue? Email security@akyla.ai rather than opening a public issue.
MIT · Built by Akyla
Comparable companies for a US stock: the subject company plus peers with valuation multiples, for relative-valuation questions ("how does compare to peers").
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock symbol, e.g. AAPL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds that it returns a peer set with multiples, which provides useful behavioral context. It does not describe details like peer selection criteria or multiple types, but with the output schema present, the additional information is adequate.
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 well-structured sentence that front-loads the core output ('comparable companies for a US stock') before adding expanding detail. Every clause serves a purpose: specifying the peer set, the multiples, and the intended use-case pattern.
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?
For a single-parameter read-only tool with a complete schema and an output schema, the description covers what the tool does and when to use it. The relative-valuation use case is explicitly stated, and no additional call-specific guidance is necessary.
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?
The input schema already fully documents the ticker parameter (100% coverage) with a clear example. The description reinforces that the ticker is for a US stock, matching the schema, but adds little beyond it. Since schema coverage is high, the baseline 3 applies.
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 identifies the tool's purpose: returning the subject company plus peers with valuation multiples for relative-valuation questions. It distinguishes itself from siblings by specifying 'valuation multiples' and 'relative-valuation', making it obvious this is for comps rather than quotes, fundamentals, or screening.
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 gives a clear usage context with the example question 'how does <company> compare to peers', which signals when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the relative-valuation framing makes the intended use case clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Headline fundamentals for a US stock in one call: revenue, EBITDA, margins, EV/EBITDA, net debt and free cash flow, plus a live quote. Best first stop for "how is doing / what are its fundamentals / is it cheap" questions.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock symbol, e.g. AAPL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already communicate readOnlyHint/openWorldHint/idempotentHint, so the safety profile is known. The description adds that the call bundles a live quote and is a headline-level summary, which is useful but does not disclose edge-case behavior, data limitations, or response size. This is acceptable given the strong annotation coverage.
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 two tight sentences: the first front-loads exactly what data the user gets, and the second gives the query intent. No filler or redundant restatement of the tool name.
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?
This is a simple one-parameter, read-only tool with an output schema and strong annotations. The description covers scope, included metrics, target audience, and typical question types, so nothing essential is missing for an agent to select and call it correctly.
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 the ticker parameter is already described as a US stock symbol with an example. The description's mention of a US stock adds no new meaning beyond the schema, so the baseline score of 3 applies.
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 tool returns headline fundamentals for a US stock and enumerates the specific metrics included (revenue, EBITDA, margins, EV/EBITDA, net debt, free cash flow, live quote). This precise inventory distinguishes it from siblings like get_quote or get_key_metrics without needing to open schemas.
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?
It gives concrete usage context: "Best first stop for 'how is <company> doing / what are its fundamentals / is it cheap' questions." This clearly implies when to use it, though it stops short of explicitly naming alternatives or stating when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full key-metrics table for a US stock across reporting periods (valuation, profitability, leverage, growth). Use when the user wants the detailed metric history rather than the single-call snapshot from get_fundamentals.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock symbol, e.g. AAPL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds useful behavioral context by clarifying that the tool returns a full cross-period table rather than a snapshot, and names the metric categories covered.
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 with no filler. The core function is front-loaded, followed by a precise routing instruction. Every sentence earns its place.
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?
This is a simple one-parameter read tool with an output schema and strong annotations. The description fully covers what the tool does and when to use it, and nothing an agent needs to invoke it correctly is missing.
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%; the ticker parameter is already described as 'US stock symbol, e.g. AAPL.' The description reinforces that this is for a US stock but does not add meaningful parameter meaning beyond the schema, so the baseline of 3 applies.
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 states a specific verb and resource: a 'Full key-metrics table for a US stock across reporting periods', and lists the metric categories. It also explicitly distinguishes itself from get_fundamentals, so an agent can tell the tools apart without opening schemas.
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?
It gives explicit when-to-use guidance: 'Use when the user wants the detailed metric history rather than the single-call snapshot from get_fundamentals.' This names the alternative and the condition that selects this tool, leaving no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Footnote disclosures (notes) from a US company's dimensional XBRL filings.
| Name | Required | Description | Default |
|---|---|---|---|
| period | No | "annual" (10-K) or "quarterly" (10-Q). | annual |
| ticker | Yes | US stock symbol, e.g. AAPL. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds a meaningful source detail (dimensional XBRL filings) but does not disclose any additional behavioral traits such as coverage limits or return shape. No contradiction exists.
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 one compact sentence with no filler. It front-loads the core data type and source. Every word contributes to understanding what the tool returns.
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 simple two-parameter schema, strong annotations, and presence of an output schema, the description is mostly sufficient. The only notable gap is lack of guidance about how this relates to sibling statement tools, but this is a minor omission for a read-only notes retrieval 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%; both ticker and period are fully documented in the schema. The tool description does not add parameter-level nuance beyond what the schema provides, so the baseline 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?
The description clearly identifies the resource returned: footnote disclosures from a US company's dimensional XBRL filings. This is distinct enough from siblings like get_quote or get_fundamentals, though it does not explicitly contrast with get_statement. It is a noun phrase rather than an explicit action, which keeps it from a 5.
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 such as get_statement or get_fundamentals. There are no exclusions, prerequisites, or hints about which scenarios call for footnotes specifically. Usage context must be inferred entirely from the tool name and title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Latest price snapshot and 52-week range for a US-listed stock.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock symbol, e.g. AAPL, MSFT, NVDA. | |
| include_history | No | If true, also return ~1 year of daily closes. |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, covering safety and side effects. The description adds context about what is returned (latest price, 52-week range) and the US-listed scope, but it does not disclose data freshness, delays, or any additional behavioral nuance. This is adequate but not rich.
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, tightly scoped sentence with no filler. It front-loads the key deliverable and adds the relevant scope. Every word earns its place.
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 simple two-parameter schema, full schema coverage, rich read-only/idempotent annotations, and an output schema, the description is complete enough for an agent to invoke the tool correctly. Nothing essential is missing for this task.
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 fully documents both ticker and include_history. The description does not need to repeat parameter details and does not add extra meaning beyond the schema. 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 names a concrete deliverable — a latest price snapshot and 52-week range — and scopes it to US-listed stocks. This is immediately distinguishable from sibling tools like get_fundamentals, get_statement, or get_comps. The resource and intent are unambiguous.
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 makes the context clear: use this for a current price snapshot and 52-week range. It does not explicitly state when not to use it or name alternatives, but the purpose is specific enough that an agent can infer the right scenario without much risk of confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
As-reported financial statement for a US stock, assembled straight from SEC
inline-XBRL. With provenance on (default), every value carries its source — the
SEC accession number, form, filing date, and inline-XBRL fact id where matchable
(derived values carry their two-term derivation instead) — so you can CITE each
number to the primary filing. Values are RAW currency units (see units).
Defaults return the latest 5 annual periods; widen period_type/latest_n only
when the question needs more history.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Which statement — "income", "balance" (balance sheet), or "cash" (cash flow). | income |
| ticker | Yes | US stock symbol, e.g. AAPL. | |
| latest_n | No | Only the newest N periods (default 5). Pass null for the full history. | |
| provenance | No | Attach per-cell SEC filing attribution to every value. Keep true for citeable answers. | |
| period_type | No | "annual" (default), "quarterly", or "all" periods. | annual |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Going well beyond the readOnlyHint/idempotentHint/openWorldHint annotations, the description discloses the provenance mechanism, how derived values are tagged, that values are raw currency units, and the default period behavior. An agent can anticipate the exact return characteristics before invoking the 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 dense sentences with no filler. The core purpose is front-loaded, and each sentence adds a distinct value: source identity, provenance behavior/units, and default tuning guidance.
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 existence of an output schema and strong annotations, the description supplies everything an agent needs to call correctly: what data is returned, how to cite it, the raw-unit caveat, and default/expansion behavior. Nothing critical is left unexplained.
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?
The input schema already covers all 5 parameters, but the description adds meaningful context: provenance attaches citeable SEC sources, derived values carry two-term derivations, values are raw units, and latest_n/period_type interact with a 5-annual default. This is above the baseline high-coverage score, though the schema still carries most naming and enum 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?
The description opens with a specific, verb-like resource: 'As-reported financial statement for a US stock, assembled straight from SEC inline-XBRL.' This clearly distinguishes it from derived or valuation-style siblings like get_fundamentals and get_key_metrics by foregrounding the SEC/as-reported nature.
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 gives parameter-level guidance ('Defaults return the latest 5 annual periods; widen period_type/latest_n only when the question needs more history') and recommends keeping provenance on for citeable answers, but it never states when to prefer this tool over siblings such as get_fundamentals or get_notes. The use case is implied by 'as-reported,' not explicitly routed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen ~5-8k US equities by valuation, size, growth and quality.
Numeric filters use the form <field>_<op> where op is one of gt, gte, lt, lte.
Values are in each field's native unit:
Money fields (marketCap, enterpriseValue, revenue, ebitda, netDebt, netIncome) are RAW USD — $10B is 10000000000, not 10000.
Ratios (pe, ps, evEbitda, evRevenue) are plain numbers.
Margins & growth (ebitdaMargin, fcfMargin, revenueGrowth, netIncomeGrowth) are decimals — 0.25 means 25%. Example — large, cheap companies: filters={"marketCap_gte": 10000000000, "pe_lte": 15} Common fields: marketCap, enterpriseValue, pe, ps, evEbitda, evRevenue, revenue, ebitda, ebitdaMargin, fcfMargin, revenueGrowth, netIncome, netDebt, price, volume.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Field to sort by (default marketCap). | marketCap |
| limit | No | Rows to return, 1-500 (default 50). | |
| order | No | "asc" or "desc". | desc |
| offset | No | Rows to skip, for paging. | |
| sector | No | Exact SIC industry description in UPPERCASE, e.g. "SEMICONDUCTORS & RELATED DEVICES". These are SIC labels, NOT GICS names — "Technology" matches nothing. Prefer numeric filters unless you know the exact SIC string. | |
| filters | No | Mapping of "<field>_<op>" -> number, e.g. {"marketCap_gte": 1e10, "pe_lte": 20}. | |
| exchange | No | Restrict to an exchange, e.g. "NASDAQ" or "NYSE". |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and open-world. The description adds meaningful behavioral context beyond those hints: the approximate universe size, the filter syntax pattern, raw USD units for money fields, decimal units for margins/growth, and the SIC-label caveat. No contradictions with annotations.
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 compact, front-loaded with the purpose, and uses scannable bullets for units and a concrete example. Every section contributes to correct invocation, and the format matches the complexity of the numeric-filter semantics without bloat.
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 output schema exists, the annotations cover safety semantics, and the input schema documents every parameter, the description provides the missing subtlety: units, operator naming, common fields, and the SIC-sector pitfall. An agent has everything needed to call this tool correctly and interpret results.
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%, so the baseline is 3. The description goes well beyond the schema by explaining native units for money fields, ratios, and growth/margin decimals, plus a concrete example. This materially reduces the risk of an agent constructing incorrect filter values like using 10000 for $10B or 25 for 25%.
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 leads with a specific verb and resource: 'Screen ~5-8k US equities by valuation, size, growth and quality.' It clearly distinguishes the tool from siblings like get_quote and get_fundamentals, which target individual securities or metrics rather than broad screening.
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 gives strong context for when to use the tool: when you need to filter a broad equity universe by numeric criteria. It also provides cautionary guidance on the sector field ('Prefer numeric filters unless you know the exact SIC string'). It does not explicitly enumerate alternatives or exclusions, but the use case is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.4.0get_compsget_fundamentalsget_key_metricsget_notesget_quoteget_statementscreen_equitiesEach tool addresses a distinct data asset (quote, fundamentals snapshot, metric history, statements, footnotes, comps, screening), so misselection risk is low. The only mild overlap is get_quote and get_fundamentals both returning a live quote, but their primary purposes are clearly separated.
All tool names use a consistent snake_case verb_noun pattern: get_* for retrievals and screen_equities for the screening action. The convention is predictable and easy to extend.
Seven tools is well-scoped for a US-equity fundamentals server: no redundancy and no tool feels extraneous. The count fits the domain comfortably.
The surface covers the fundamental-analysis workflow well: snapshots, detailed metrics, statements, footnotes, peer comps, and screening. Minor gaps like direct ticker search or historical price series would be nice, but agents can work around them for the core use case.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries
SEC dilution data, live market data, and news for U.S. equities, with point-in-time as-of queries.
Market data, financial statements, valuation, research, and news for investment workflows.
Financial statements, metrics, dividends, and price data for public companies.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/AkilaAnalytics/akyla-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
