Solar Sathi MCP

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation5/5
Each tool has a clear, distinct purpose: data retrieval, cost estimation, capacity calculation, subsidy calculation, ROI analysis, environmental impact, and assessment persistence. There is no overlap or ambiguity between the tools.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern: get_, estimate_, calculate_, save_. Most calculation tools use 'calculate_' with only one using 'estimate_', which is a minor acceptable deviation. The pattern is clear and predictable.
Tool Count5/5
With exactly 8 tools, the server is well-scoped for a solar assessment domain. Each tool covers a distinct step in the workflow, and the count feels appropriately sized—not bloated or sparse.
Completeness5/5
The tool set covers the full assessment lifecycle: weather data input, cost estimation, capacity planning, subsidy calculation, ROI analysis, environmental impact, and storing/retrieving assessments. No critical operations are missing for the intended purpose.
Average 3.6/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It lists output metrics but does not state that this is a pure calculation with no side effects, nor does it mention assumptions (e.g., lifetime definition, discount rate), units for 'savings' or 'payback period', or how the metrics are derived. The description stays at the level of intent without exposing operational behavior.
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, focused sentence that front-loads the primary action and enumerates the key outputs. There is no unnecessary information or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool and the richness of the input schema, the description is minimally viable. It lists the outputs, which partially compensates for lacking an output schema, but it does not clarify units for savings/payback period or define 'lifetime'. The description is adequate but leaves some interpretive gaps, particularly for a calculator with optional parameters like system size and CO2 reduction.
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%, with every parameter having a clear description and units. The tool description adds no parameter-specific details beyond the schema, but the baseline of 3 applies because the schema already handles parameter semantics adequately.
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 function with a specific verb ('Calculate') and resource ('ROI metrics'), and lists concrete outputs (final cost, savings, payback period, lifetime savings, ROI %). This distinguishes it from sibling tools like calculate_subsidy or calculate_environmental_impact, which target different metrics.
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. It does not mention any prerequisites, conditions for use, or contrast with sibling tools. While the purpose is clear, a user could benefit from knowing this is the choice when ROI or payback period is needed, but no such direction is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not reveal that cost_per_kw is optional, assume a default value, or clarify what the returned cost includes (e.g., taxes, labor). The behavior beyond the statement is opaque.
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, direct sentence that immediately states the tool's function. There is no redundancy or filler, making it exemplary in conciseness, even though it lacks some contextual details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with only two parameters and no output schema, the minimal description is adequate but leaves gaps: it does not mention what the estimated cost represents, whether the cost_per_kw parameter has a default, or the format of the returned value. More context would complete the picture.
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 provides 100% description coverage for both parameters, so a baseline score of 3 is appropriate. The description adds the overall purpose but does not elaborate on how parameters interact, such as the implied multiplication of capacity_kw and cost_per_kw.
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 uses the specific verb 'estimate' and clearly names the resource 'total installation cost' for a solar system. This distinguishes it from sibling tools like calculate_capacity or calculate_subsidy, which address other aspects of solar analysis.
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?
No guidance is provided about when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or other suitable tools. Given the sibling tools, the agent is left without explicit context for choosing this function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what is calculated without disclosing behavioral traits such as assumptions (e.g., default solar irradiance), whether the calculation is deterministic, or if any external data is required. The agent has no information on potential side effects or limitations.
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, concise sentence that front-loads the purpose and lists the key outputs. Every word earns its place; no redundant or vague phrasing is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the tool is simple with one parameter, the description omits output format details (units for energy/CO2, nature of 'trees saved') and any underlying assumptions. Without an output schema, the agent cannot fully anticipate the response structure, leaving the description partially complete.
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 single parameter capacity_kw is fully described in the schema (100% coverage), and the description adds no additional semantics. The baseline is 3, as the schema carries the parameter meaning and the description doesn't augment it.
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 uses a specific verb ('calculate') with a clear resource ('environmental impact') and enumerates three specific output metrics (annual energy generation, CO2 reduction, trees saved). This distinguishes it from sibling calculators like calculate_roi or calculate_subsidy, which focus on financial metrics.
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 implies use for environmental impact calculations but provides no explicit guidance on when to prefer this tool over alternatives, nor any exclusions. The agent must infer suitability from the tool name and output list, which is only implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the basic action without mentioning side effects, overwrite behavior, auth requirements, or return value. For a write operation, this is a significant gap.
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, front-loaded sentence with no redundant words. Every phrase contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 parameters, no annotations, and no output schema, the description is too short to cover important context like what is returned, prerequisites (e.g., email/phone requirement), or how saving relates to other tools like get_assessment_history. It leaves the agent without critical operational guidance.
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%, so the baseline is 3. The description adds only a high-level grouping ('homeowner details' and 'calculated results') which provides minimal added meaning beyond the schema's per-parameter descriptions.
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 uses a specific verb ('Save') and a specific resource ('a solar assessment'), clearly stating the action and object. It distinguishes itself from sibling calculation/retrieval tools by focusing on persistence.
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 phrase 'for future reference' implies this tool is for persisting results after calculations, and the sibling set contains no other save tool. However, it does not explicitly state when not to use it or name alternatives.
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?
There are no annotations, so the description carries the burden. It discloses that the calculation uses a tiered structure, which hints at the method, but does not explicitly state that the tool is read-only, what the return value looks like, or any limitations (e.g., assumes current scheme rates). For a simple calculator, this is adequate but not highly transparent.
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, front-loaded sentence that wastes no words. It immediately states the action, target, and key detail (tiered structure).
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?
The tool is simple with one parameter and no annotations, but there is no output schema, so the description could specify the return format (e.g., subsidy amount in currency). It is mostly complete for a straightforward calculator, but leaves minor ambiguity about output structure.
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 schema already provides full coverage for the single parameter (capacity_kw) with a description and constraints. The tool description adds no additional meaning beyond restating 'system capacity' and referencing the tiered structure. Baseline 3 applies since schema coverage is 100%.
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 uses a specific verb ('Calculate') and clearly identifies the resource ('PM Surya Ghar subsidy') and scope ('given system capacity using the tiered structure'). This distinguishes it from sibling tools like calculate_roi or estimate_installation_cost, making its purpose unambiguous.
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 implies usage for subsidy calculation based on capacity, but provides no explicit guidance on when to choose this tool over siblings, nor any exclusions or prerequisites. It does not state, for example, that it is the appropriate tool when the user asks for subsidy amounts rather than ROI or installation costs.
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?
No annotations are provided, so the description carries the full burden. It clearly signals a read operation through 'retrieve' and specifies scope ('all previously saved'), but it does not disclose any edge cases such as whether at least one of phone/email is required, what happens when no results exist, or any pagination/ordering behavior. This is adequate but lacks depth.
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 conveys the action, target, and scope without any redundant or extraneous words. It is maximally concise while remaining informative.
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?
For a simple tool with two optional parameters and no output schema, the description successfully conveys the tool's purpose and the key lookup dimensions. The phrase 'all previously saved solar assessments' implies a list return. It does not explicitly discuss parameter optionality or combination logic, but these are minor gaps given the tool's simplicity.
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%, so the baseline is 3. The description adds meaningful context by indicating that email and phone are the lookup keys for the homeowner, which goes beyond the schema's bare 'Email address' and 'Phone number' descriptions. However, it does not clarify whether they are alternative or combined filters, which is a minor gap.
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 uses a specific verb ('Retrieve') and clearly identifies the resource ('all previously saved solar assessments') and the lookup method ('by phone or email'). This distinguishes it from sibling tools that handle calculations or irradiance, and it aligns with save_assessment as the read counterpart.
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 implies usage for looking up past assessments, but it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusions or prerequisites. The context suggests it is for historical retrieval rather than new calculations, but this is left implicit.
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?
With no annotations, the description carries the full burden. It discloses the external API (Open-Meteo) and the return unit (kWh/m²), but does not clarify the time period over which the 'average daily' value is calculated, nor does it mention error behavior, rate limits, or other caveats. This is adequate but not fully transparent.
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 concise sentences that directly state the tool's purpose and return value. There is no redundant content, and key details are front-loaded.
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's simplicity, the description is nearly complete: it names the data source, specifies inputs implicitly via schema, and provides the return unit. The only notable gap is the ambiguous averaging period for the 'average daily' radiation, which prevents a perfect score.
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 for parameters is 100%, with clear per-parameter descriptions for latitude and longitude. The description adds value by specifying the output format (kWh/m²), but does not need to elaborate on parameter semantics since the schema fully covers them.
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 action ('Fetch') and the resource ('solar irradiance data') along with the geographic context ('for a geographic location'). It distinguishes itself from sibling tools that focus on calculations (e.g., 'calculate_solar_capacity') or saving/retrieving assessments by indicating it retrieves raw data from a specific API.
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 implies usage: when you need solar irradiance data for a location, before downstream calculations. However, it does not explicitly state when to prefer this over alternatives or mention any exclusions, so the guidance is only implicit.
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?
With no annotations, the description carries the burden. It clearly indicates a read-only calculation, but does not disclose formula assumptions, output format, or limitations. The word 'recommended' hints at a heuristic, but no further detail is given. 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 concise sentence, front-loaded with the core purpose, and every word earns its place. It avoids unnecessary detail while conveying the essential inputs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple calculation with no output schema, and all parameters are documented in the schema. The description provides the purpose and inputs but lacks detail on return values, edge cases, or relationship to sibling tools. Adequate for a straightforward tool, but not fully complete.
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%, so baseline is 3. The description names three of four parameters (monthly bill, tariff, roof area) but omits the optional monthly_units. It adds minimal semantic value beyond the schema, so a 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 uses a specific verb ('Calculate') and resource ('recommended solar system capacity'), clearly distinguishing it from sibling tools that handle irradiance, costs, subsidies, ROI, etc. It leaves no ambiguity about what the tool computes.
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 states clear context: the tool is used to calculate capacity based on monthly bill, tariff, and roof area. It does not explicitly mention alternatives or when-not-to-use, but the inputs imply a specific scenario, making it clear when this tool is appropriate relative to siblings.
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

Copy to your README.md:

[![mcp_solor_sathi MCP server](https://glama.ai/mcp/servers/Prajwal1103-hack/mcp_solor_sathi/badges/card.svg)](https://glama.ai/mcp/servers/Prajwal1103-hack/mcp_solor_sathi)

Score Badge

Copy to your README.md:

[![mcp_solor_sathi MCP server](https://glama.ai/mcp/servers/Prajwal1103-hack/mcp_solor_sathi/badges/score.svg)](https://glama.ai/mcp/servers/Prajwal1103-hack/mcp_solor_sathi)

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/Prajwal1103-hack/mcp_solor_sathi'

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