akyla-mcp

Official

by AkilaAnalytics

Overview Schema Source Related Servers Score Discussions Admin

Python

Hybrid

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.4.0
Disambiguation4/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
Seven tools is well-scoped for a US-equity fundamentals server: no redundancy and no tool feels extraneous. The count fits the domain comfortably.
Completeness4/5
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.
Average 4.2/5 across 7 of 7 tools scored. Lowest: 3.4/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness5/5
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.
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 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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

akyla-mcp MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![akyla-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/AkilaAnalytics/akyla-mcp/badges/card.svg)](https://glama.ai/mcp/servers/AkilaAnalytics/akyla-mcp)

Score Badge

Copy to your README.md:

[![akyla-mcp MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/AkilaAnalytics/akyla-mcp/badges/score.svg)](https://glama.ai/mcp/servers/AkilaAnalytics/akyla-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/AkilaAnalytics/akyla-mcp'

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