portfolio-mcp

by NawafSheikh

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v0.1.0
Disambiguation3/5
Most tools have distinct purposes, but there is clear overlap between git_overview and stale_projects, and deployment_map/list_projects both surface deployment information. Descriptions are detailed enough to guide selection, but a few boundaries are fuzzy.
Naming Consistency4/5
Tool names are consistently lowercase snake_case and mostly follow a descriptive scope_action or scope_noun pattern. However, not all names use the same verb_noun convention — deployment_map, git_overview, outdated_deps, and stale_projects are noun/adjective-led rather than verb-led.
Tool Count5/5
Twelve tools is well within the ideal range and each tool contributes to a coherent portfolio analysis workflow. The count feels appropriate for the server's purpose without unnecessary bloat or noticeable thinness.
Completeness4/5
The tool surface covers listing, searching, deep inspection, health checking, git state, dependency security, and monetization analysis, which is strong for an analysis-focused portfolio MCP. Minor gaps exist, such as no project creation/update/delete tools, but these are not clearly required by the domain.
Average 3.5/5 across 11 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- Last stable release on August 22, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. It implies a read-only operation by using 'Get', but it does not disclose output format, performance implications, error behavior, or whether any side effects or prerequisites exist.
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 immediately identifies the tool's purpose and then lists the specific information categories. There is no wasted wording 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter) and the schema fully documents that parameter, but there is no output schema and no annotations. The description lists what information is returned but does not explain return structure, failure modes, or when to prefer specialized siblings, leaving some gaps.
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%: the only parameter, 'name', is described as 'Project directory name'. The description adds no extra meaning beyond that, but with full schema coverage 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 states a specific verb ('Get') and resource ('one project') and enumerates the information domains: stack, deps, git, deployment, revenue readiness, LOC. This is clear and distinct from list_projects or search_projects, though it does not explicitly name or contrast sibling tools.
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?
There is no guidance on when to use this tool versus siblings like git_overview, revenue_scan, outdated_deps, or deployment_map. The description implies it is for a comprehensive single-project overview, but it does not state exclusions or alternatives.
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 carries the full burden of behavioral disclosure. It conveys a generation behavior but does not state whether the operation is read-only, whether it requires access to project data, what side effects exist, or what failure modes may occur. 'Generate' is not enough to establish safety or 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 concise sentence with no filler. It front-loads the scope and clearly states the output and ordering, making it efficient and easy to parse.
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 simple with one required parameter and no output schema, and the description gives the basic input-output relationship. However, with no annotations and no output schema, it omits return format details, side-effect expectations, and sibling differentiation, leaving notable gaps for an agent deciding how to invoke it.
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 only parameter is clearly described as 'Project directory name'. The description adds only the phrase 'for a project', which mirrors the schema rather than enriching it, so it earns the baseline score without additional semantic value.
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 states a clear action ('generate'), a resource ('for a project'), and a specific output property ('concrete monetization steps in priority order'). It does not explicitly differentiate from siblings like revenue_scan or find_opportunities, so sibling distinction is implicit rather than stated.
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 given on when to use suggest_actions versus the related sibling tools such as revenue_scan or find_opportunities. The phrase 'for a project' gives minimal context but no exclusions, prerequisites, or alternative routing.
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 to rely on, the description must convey behavioral traits. It only states what the tool checks, but does not disclose whether it performs read-only operations, what the return format is, potential side effects (e.g., network access for vulnerability scanning), or error behavior. This leaves significant ambiguity.
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 primary action and scope. There is no redundant information or unnecessary verbosity.
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?
Without an output schema, the description should explain the return value or expected outcome, but it does not. It also fails to mention any prerequisites or context (e.g., whether the project must already be initialized, or what happens if dependencies are unavailable). The description is too sparse for an agent to fully understand the tool's behavior.
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 fully covers the only parameter 'name' with a clear description ('Project directory name'), so baseline for schema coverage is met. However, the tool description does not add any extra meaning beyond the schema, such as expected format or constraints.
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 specific purpose: checking a project for outdated npm/pip dependencies and security vulnerabilities. The verb 'Check' and the explicit scope (dependencies and vulnerabilities) make it distinguishable from sibling tools like stale_projects or check_health.
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 on when to use this tool versus alternatives. There is no mention of conditions that would favor this tool over others, nor any exclusion criteria. The description is implicit but lacks explicit usage instructions.
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 carries the burden. It only says 'pings known URLs,' which hints at network behavior, but does not disclose potential side effects (e.g., latency, failures, rate limits) or what the response contains. This is a significant gap for a tool that performs an external action.
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 short sentences, efficient and free of extraneous information. It conveys the core purpose without redundancy.
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 simple health-check tool, the description covers the action and scope but omits output details (e.g., return format, what 'reachable' means) and potential failure behavior. Given no annotations and no output schema, this is a moderate gap.
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 single parameter 'project' is 100% covered by the schema with its description 'Project directory name'. The tool description reinforces this by mentioning Vercel/Netlify projects. It doesn't explain the mapping from name to URLs, but the parameter itself is clearly defined.
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 uses a specific verb ('Check') and resource ('deployed project') and mentions Vercel/Netlify, making the purpose clear. It doesn't explicitly differentiate from sibling tools like deployment_map, but the focus on reachability is distinct enough.
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 verifying deployment reachability, but it doesn't explicitly state when to choose this over alternatives like deployment_map or get_project. It gives context (Vercel/Netlify) but no explicit exclusions or comparisons.
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 of signaling behavior; 'List' and the return-field list indicate a read-only enumeration, and 'optional filters' implies no filters returns all projects. However, it does not clarify how multiple filters combine, default ordering, or pagination, though these are minor for a simple list 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?
Two concise sentences front-load the main action and list the returned fields with no filler. Each sentence earns its place.
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 low-complexity tool with fully documented parameters, the description covers the missing output contract by listing return fields, since there is no output schema. It lacks explicit routing to search_projects and filter-combination semantics, but the core calling contract is present.
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 input schema fully documents all four parameters. The description adds only the generic phrase 'optional filters' and provides no additional meaning beyond what the schema already states.
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 states a specific verb ('List'), the resource ('projects'), and the returned fields, making the tool's job clear. It is clearly the bulk-listing counterpart to get_project, but it does not explicitly differentiate itself from search_projects.
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 list_projects versus search_projects or stale_projects. The optional filters imply some use cases, but there is no explicit when-to-use or when-not-to-use statement.
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 carry the full behavioral burden. It states the tool reads project data and sorts by staleness, but it does not disclose what 'staleness' means precisely beyond 90+ days, whether the tool performs any side effects (unlikely), what data it returns (e.g., project names, last commit dates), or any limits on the number of results. For a read-only tool, this lack of return format and edge-case behavior is a notable 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, clear sentence that front-loads the core purpose (find projects with no commits) and includes the key detail (90+ days, sorted by staleness). It contains zero fluff and every word earns its place, making it appropriately concise and well-structured.
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 tool has no parameters, no output schema, and no annotations, the description is relatively complete for a simple read-only query, but it lacks details about the output format (e.g., does it return project IDs, last commit dates?) and the sorting order (ascending vs descending staleness). While the tool appears simple, a slightly richer description of the return values would improve its completeness.
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 tool has 0 parameters, and the schema coverage is 100% (empty schema). With no parameters, the description doesn't need to explain parameter semantics. The baseline for 0 params is 4, and the description correctly does not introduce any unnecessary parameter details, earning that baseline.
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 states the tool's function: finding projects with no git commits in 90+ days and sorting by staleness. It specifies the resource (projects), the action (find), and the key criterion (no commits in 90+ days). It distinguishes itself from siblings like git_overview and list_projects, which are broader, though it doesn't explicitly name an alternative.
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 when to use it (to identify stale projects) but does not explicitly state when not to use it or mention any alternatives. For example, it doesn't say to use list_projects for all projects or git_overview for general git activity. The 90-day threshold gives clear context, but the lack of exclusions or alternative mentions leaves the guideline partly 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?
Discloses specific detection criteria (uncommitted changes, no remote, 90-day stale threshold), which is useful. However, with no annotations provided, the description carries full burden and doesn't state whether the scan is read-only, whether it performs network I/O, or what the output looks like.
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?
Single, front-loaded, 16-word sentence that wastes no words. Every element ('all projects', 'git state', the three checks) 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?
Covers what the tool checks, which is essential, but omits what it returns (list, summary, flags) and any side effects. Given no output schema or annotations, this is a meaningful gap for a scan-type tool.
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?
Tool has zero parameters, so the empty schema is fully covered. Description adds no parameter semantics needed; baseline of 4 for 0-param tools 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?
Clear verb 'scan' + resource 'all projects' with specific git states listed (uncommitted changes, no remote, stale repos). However, it doesn't differentiate itself from sibling 'stale_projects', which overlaps with the 'stale repos' check.
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?
Implies a cross-project overview but never states when to use this over siblings like 'stale_projects' or 'list_projects'. No explicit exclusions or alternatives, leaving usage to inference.
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?
Annotations are absent, so the description carries the burden of behavioral disclosure, but it reveals no traits such as read-only status, rate limits, pagination, or side effects. The term 'search' implies safety, but that is left to inference. The description adds no behavioral context beyond the operation's purpose.
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?
A single, front-loaded sentence with zero filler. Every word contributes meaning, and the structure immediately communicates the tool's purpose without repetition.
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 tool with one plain-string parameter and no output schema, the description is sufficient to guide correct usage. It tells the agent what the query does and which fields are searched. The only minor omissions are details about result format or pagination, which are not critical for such a simple search interface.
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 schema only provides 'Search term,' but the description enriches this by clarifying that the query matches against project names, READMEs, package descriptions, and dependency names. This tells the agent what information the parameter should contain and how to use it effectively. While the description doesn't add syntax details, the 100% schema coverage and this additional context justify a score above baseline.
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 'search' and defines the resource as project names, READMEs, package descriptions, and dependency names. This clearly distinguishes it from siblings like list_projects and get_project, which use different verbs and scopes. A concise, non-redundant statement beyond the tool name.
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 given about when to prefer this tool over siblings such as list_projects, find_opportunities, or git_overview. The description only states what it searches, not when an agent should use it or which alternatives exist for specific cases. There is no mention of exclusions or disclaimers.
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 carries the full burden of behavioral disclosure. It fails to mention whether the operation is read-only, what it returns, how long it might take, or any side effects. The only behavioral hint is the broad scope ('ALL projects'), which implies potential cost, but no details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that leads with the action ('Scan ALL projects') and lists the key subjects. It avoids fluff, though the final clause 'Claude uses this to build better' is somewhat promotional and could be omitted. Overall, it is concise and front-loaded.
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?
With no output schema, no annotations, and zero parameters, the description is the sole source of context. It fails to explain what the tool returns (e.g., a summary, report, or learning embedded in the agent), how the results are used, or any prerequisites. This is especially inadequate for a tool that scans all projects, as agents might need to know about performance or outcome format.
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 tool has zero parameters and the input schema is effectively empty (100% schema coverage). The description correctly adds no parameter documentation because none exist. A baseline of 4 is appropriate since there is nothing to confuse an agent about arguments.
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 purpose: to scan all projects and learn the developer's patterns, explicitly listing the kinds of patterns (frameworks, stacks, architecture, strengths). It distinguishes itself from sibling tools like list_projects and search_projects by focusing on pattern extraction rather than listing or searching individual projects.
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 implies usage context by stating 'Claude uses this to build better,' which suggests it should be used when the agent needs to tailor its output to the developer's style. However, it does not explicitly mention when NOT to use it or point to alternative tools, so guidance is incomplete but still reasonably clear.
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?
No annotations are provided, so the description carries the full burden. It clearly discloses the tool performs a read-only analysis (checks) without mentioning destructive actionscars. It also specifies the output (score 1-10, suggested path), which is helpful. It doesn't note any auth requirements or side effects, but as an analysis tool, it's reasonably transparent. However, it doesn't explicitly state whether it alters anything, but 'analyze' and 'checks' imply read-only, so it's acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise, two sentences: purpose and output. No fluff. Clear structure.
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?
It lacks info about when to use vs alternatives, no exclusions. Given many sibling tools (deployment_map, check_health), it doesn't distinguish. But it does state specific scope. However, no mention of required context like whether project must be deployed first or what happens if not ready. Also no mention of auth or rate limits. Slightly incomplete.
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?
No input schema is provided, so the description must describe parameters. It says 'a project' but doesn't specify what identifies the project (ID? URL?). The description lists what it analyzes (auth, payments, etc.) but not how to supply the project reference. With no schema, the agent has no parameter details. So 3.
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 ('Analyze'), a concrete resource ('a project's monetization readiness'), enumerates the exact areas checked (auth, payments, landing page, deployment, API, README), and states the output (a 1-10 score and suggested path). This clearly distinguishes it from sibling tools like git_overview or check_health.
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 when evaluating a project's monetization readiness)Skip but does not explicitly state when not to use it or contrast with alternative tools such as find_opportunities or suggest_actions. The scope is clear enough that an agent can infer the context, but no explicit guidance is given.
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 communicates that results are 'grouped by platform' and includes 'local-only' status, but it does not disclose whether this is a live fetch, cached snapshot, or whether any auth/network behavior is involved. That gap is moderate for a zero-parameter overview 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?
The description is a single, efficient sentence with zero filler. It front-loads the purpose, enumerates the full scope of platforms, and adds the output grouping constraint without redundancy.
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 no-parameter tool with no output schema, the description gives enough context: what is covered and how the output is organized. It could additionally hint at whether the overview includes statuses or health, but the current level is sufficient for correct invocation and expectations.
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?
There are zero parameters in the schema, so parameter semantics are not a concern. The 0-parameter baseline of 4 applies; the description does not need to add parameter meaning when there are no parameters to document.
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 (deployment overview) and enumerates the specific platforms covered: Vercel, VPS, Netlify, Railway, Docker, and local-only. This distinguishes it from siblings like list_projects or git_overview, though it does not explicitly frame it as a verb like 'return' or 'map'.
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 'Full deployment overview' plus the platform enumeration gives a clear context for when to use this tool: when an agent needs to see deployment targets across environments. It does not explicitly state when not to use it or name a sibling alternative, but the scope is well implied by the description.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does this well by stating that the tool ranks all projects and returns a well-specified set of outputs: scores, what is ready, what is missing, effort estimate, and suggested pricing. It does not note permission requirements or data-freshness caveats, but for a zero-parameter read/analysis tool, the behavioral description is strong.
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 sentences with no filler. The core action is front-loaded in the first sentence, and the second sentence lists the return contents compactly. Every phrase adds information.
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 no-input tool without an output schema, the description is nearly complete: it says what the tool ranks, the basis of ranking, and the exact categories of information returned. The main gap is positioning relative to revenue_scan and other sibling tools, but that is more about usage guidance than the tool's own behavior.
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 is empty with zero parameters, so there is no parameter burden to compensate for. The description adds no parameter details, but none are needed. The baseline of 4 applies because there are no parameters to document.
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 states the verb 'Rank' and the resource 'ALL projects', and explicitly says it ranks by revenue potential. It also enumerates the output components (scores, readiness, gaps, effort estimate, pricing), which makes the purpose concrete. However, it does not explicitly differentiate from the sibling revenue_scan, which may also be revenue-related.
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 intended use is implied: use this when you need projects ranked by revenue potential and supporting opportunity details. But the description gives no explicit when-to-use/when-not-to-use guidance and does not mention alternatives like revenue_scan, suggest_actions, or list_projects. The context is clear enough to infer, but not stated.
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:

[![portfolio-mcp MCP server](https://glama.ai/mcp/servers/NawafSheikh/portfolio-mcp/badges/card.svg)](https://glama.ai/mcp/servers/NawafSheikh/portfolio-mcp)

Score Badge

Copy to your README.md:

[![portfolio-mcp MCP server](https://glama.ai/mcp/servers/NawafSheikh/portfolio-mcp/badges/score.svg)](https://glama.ai/mcp/servers/NawafSheikh/portfolio-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/NawafSheikh/portfolio-mcp'

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