Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ph-data-mcp-server Incoming college ako, BS Engineering. Anong scholarship pwede?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that gives AI assistants (Claude, Cursor, VS Code Copilot, and others) Philippine data: scholarships, holidays, regions, universities, peso exchange rates and weather.
Ask your assistant things like:
"Incoming college ako, BS Engineering. Anong scholarship pwede?" "Which regular holidays fall on a Monday in 2027?" "List state universities in Region X and the scholarships open to their students."
No API key needed.
Tool | What it does | Data |
| Find scholarships that match a question (English or Taglish), optionally by level | Bundled, offline |
| Full eligibility, benefits, period, how to apply, official link | Bundled, offline |
| Browse with filters: level, provider type, region | Bundled, offline |
| Regular and special holidays (2026–2027) | Live |
| All 17 regions with codes and centers | Live |
| Universities and colleges by region and type | Live |
| Convert to or from PHP at daily rates | Live |
| Current weather in major cities | Live |
Every tool is read-only and supports response_format: "json" for structured output.
About the scholarship data: 35 programs (DOST-SEI, CHED, TESDA, OWWA, DSWD, GSIS, DepEd, Quezon City, Davao, Cagayan de Oro, SM, Megaworld, Gokongwei, Security Bank, Aboitiz, DLSU, Ateneo, UST), each checked against the provider's own page. Details the official page doesn't state are null, never guessed. It's the same dataset as Iskolar AI. Programs change every school year, so always confirm on the official page.
The live tools use the free Philippines Public Data API.
Related MCP server: PH Schools MCP Server
Requires Node.js 20.3 or later.
Claude Code
claude mcp add ph-data -- npx -y ph-data-mcp-serverClaude Desktop (claude_desktop_config.json), Cursor (.cursor/mcp.json) and most other clients:
{
"mcpServers": {
"ph-data": {
"command": "npx",
"args": ["-y", "ph-data-mcp-server"]
}
}
}VS Code (.vscode/mcp.json):
{
"servers": {
"ph-data": { "type": "stdio", "command": "npx", "args": ["-y", "ph-data-mcp-server"] }
}
}Docker
docker build -t ph-data-mcp-server .
docker run -i --rm ph-data-mcp-servergit clone https://github.com/CharlieJamesGwapo/ph-data-mcp-server.git
cd ph-data-mcp-server
npm install
npm run build
npm run smoke # calls every tool through a real MCP client
npx @modelcontextprotocol/inspector node dist/index.js # interactive testingPH_API_BASE_URL points the live tools at another deployment of the API.
Bump version in package.json, server.json (both places) and src/index.ts.
npm publish (the prepublishOnly script builds first).
mcp-publisher login github then mcp-publisher publish to update the MCP Registry entry.
Scholarship fixes and additions are welcome. Edit data/scholarships.json, cite the provider's own page (not a blog or aggregator), and set last_checked to today.
If this is useful, ⭐ star the repo or sponsor the maintainer.
MIT License. Not affiliated with any agency, foundation or school listed.
Convert an amount between currencies using current exchange rates based on the Philippine peso (PHP), e.g. 100 USD to PHP. Rates come from open.er-api.com and update daily.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | 3-letter currency code to convert to (default PHP) | PHP |
| from | Yes | 3-letter currency code to convert from, e.g. "USD" | |
| amount | No | Amount to convert | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=false; the description adds the genuinely useful context that rates come from open.er-api.com and are refreshed daily, which tells the agent the data is external and can be a day stale. It does not say what happens with an unrecognized currency code or whether the daily rate can change results between calls, which is why it is not a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero padding: the conversion scope and example come first, the data source and update cadence second. Every clause carries information an agent would otherwise have to guess.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter, single-operation tool with full schema coverage and annotations covering the safety profile, the description supplies enough to call it correctly, and response_format makes an output schema unnecessary. The only gap is failure behavior for invalid codes or provider outages, which is minor at this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so every parameter including the amount bounds and response_format enum is already documented. The description only reinforces the currency-code convention via the "100 USD to PHP" example and adds nothing about the PHP default target beyond what the schema states; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (convert) and resource (currency amounts) plus the scope: rates are cross-rates based on the Philippine peso, e.g. "100 USD to PHP". It also names the rate provider, so an agent knows this is a live-rate conversion rather than a static table lookup, and none of the siblings (weather, holidays, scholarships, regions) overlap with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The worked example ("100 USD to PHP") implies the usage context, but there is no explicit when-to-use or when-not-to-use statement. Because no sibling tool performs currency conversion, the routing risk is low, so this is adequate rather than strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full details of one Philippine scholarship by id (from ph_search_scholarships or ph_list_scholarships): eligibility, benefits, application period, how to apply, official and source URLs, and the date it was last checked. Fields the official page does not state are null.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Scholarship id, e.g. "dost-sei-ra7687" or "owwa-edsp" | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, so the safety profile is covered. The description adds useful behavioral context beyond them: the null convention for fields the official page omits, plus the last-checked timestamp that signals data freshness. It does not describe error behavior for a missing id.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence that front-loads the identity and scope, then the returned fields, then the null convention. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the returned fields and the null-data rule, and the response_format parameter is documented in the schema. An agent has everything needed to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, including an example id format and the response_format enum, so the baseline is 3. The description adds provenance meaning for the id (which tools emit it) and links response_format implicitly to 'full details', giving a modest lift beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb and resource ('Full details of one Philippine scholarship by id') and enumerates the payload (eligibility, benefits, application period, how to apply, URLs, last-checked date). This clearly separates it from the list/search siblings, which return multiple records rather than one full record.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names the two sibling tools that produce a valid id (ph_search_scholarships, ph_list_scholarships), which is real routing guidance. It does not explicitly state the prerequisite 'obtain an id first' or what happens with an unknown id, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current weather (temperature, humidity, feels-like, rain, wind) for a major Philippine city, from Open-Meteo. Use a city slug such as "manila", "quezon-city", "cebu-city", "davao-city" or "cagayan-de-oro".
| Name | Required | Description | Default |
|---|---|---|---|
| city | Yes | City slug, e.g. "manila" or "cebu-city" | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true and idempotentHint=false, so the safety and external-call profile is covered. The description usefully discloses the upstream provider (Open-Meteo) and, via 'major Philippine city', that coverage is limited rather than global. It still omits units (Celsius/Fahrenheit), error behavior for unknown slugs, and why results are non-idempotent (they change over time), so it adds context but not full behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what the tool returns before the argument convention. Every clause carries information (metric list, source, slug format) with no filler or repetition of the title.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With only two parameters, no output schema, and no nested objects, the definition is nearly complete: the parenthetical field list effectively substitutes for a missing output schema. The only real gap is the absence of unit and error-handling detail, which is a minor omission for a read-only lookup tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the parameters are already documented and the baseline is 3. The description earns an extra point by extending the slug convention beyond the schema's two examples to five ('manila', 'quezon-city', 'cebu-city', 'davao-city', 'cagayan-de-oro'), making the lowercase-hyphenated '<city>-city' pattern obvious and reducing malformed-input risk.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb+resource ('Current weather ... for a major Philippine city') and enumerates the returned fields (temperature, humidity, feels-like, rain, wind) plus the upstream source (Open-Meteo). It is unambiguously distinct from all siblings (currency, scholarships, holidays, regions, schools), so an agent can select it without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The word 'Current' implicitly scopes the tool to present conditions rather than forecasts or history, and the slug examples imply how to supply the argument. However, there is no explicit when-to-use/when-not guidance and no named alternative for non-major cities or for forecasts, so the agent must infer the boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Philippine regular and special non-working holidays (currently 2026 and 2027), with date, name and type. Example: "When is Holy Week 2027?" or "regular holidays this year".
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | 'regular' or 'special' (non-working) | |
| year | No | Year, e.g. 2026 | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, idempotent, and openWorld behavior, so the description's main added value is disclosing the actual data coverage ('currently 2026 and 2027') — important because the schema permits 2000-2100. It does not say whether an out-of-range or out-of-coverage year yields an empty result, an error, or an extrapolation, which is the remaining behavioral gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences with the content and coverage stated first and examples second, so nothing important is buried. The nested quotation inside the description is slightly awkward stylistically but does not impede comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, zero-required-parameter lookup tool with full schema coverage and read-only annotations, the description supplies what an agent needs: what is returned and which years exist. The only meaningful omission is explicit behavior for years outside the stated 2026-2027 coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all three parameters, including both enums and the response_format default, are already fully documented. The description adds only a light illustration of how year and type combine; it provides no syntax or format detail beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Philippine regular and special non-working holidays), states the scope of data coverage (2026 and 2027), and lists the returned fields (date, name, type). It is instantly distinguishable from the sibling tools, which cover currency, weather, regions, schools, and scholarships.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The two example queries ('When is Holy Week 2027?' and 'regular holidays this year') effectively illustrate the question shapes this tool answers, including the combination of type and year filters. There are no explicit exclusions or guidance on what to do when a year outside 2026-2027 is requested.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 17 regions of the Philippines with code (e.g. NCR, R10, BARMM), name, island group and regional center. Use the codes as the region filter in ph_list_schools.
| Name | Required | Description | Default |
|---|---|---|---|
| island_group | No | Only regions in this island group | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/idempotent/openWorld, so the safety profile is covered. The description adds value annotations do not: the result set is a fixed, complete set of 17 regions and each row carries four named fields, implying no pagination and exhaustive coverage. It does not discuss auth or rate limits, which is acceptable for a small static reference call.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with what is returned, followed by the actionable routing tip. No redundant restatement of the title or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by naming the exact fields returned and the universe of results (17 regions). For a simple read-only reference lookup with fully documented parameters and annotations, nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with documented enums for both island_group and response_format, so the schema carries parameter meaning. The description adds no syntax or behavioral detail about filtering by island group or the effect of response_format, leaving it at the baseline for fully documented schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Names a specific resource with an exact scope ('The 17 regions of the Philippines') and enumerates the returned fields (code, name, island group, regional center) with example code formats (NCR, R10, BARMM). An agent can distinguish this listing tool from ph_list_schools or ph_get_weather without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a concrete downstream use: 'Use the codes as the region filter in ph_list_schools', which tells the agent when this tool is a prerequisite step. It does not name a distinct alternative to this tool or state exclusions, but no sibling lists regions, so the routing gap is small.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Browse the full curated list of Philippine scholarships with optional filters (level, provider type, region). Use ph_search_scholarships instead when you have a specific question.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | School level: senior_high, college, graduate, or tech_voc (TESDA) | |
| limit | No | Maximum number of programs | |
| offset | No | Number of programs to skip, for pagination | |
| region | No | Text to match in the regions served, e.g. "NCR", "Davao", "nationwide" | |
| provider_type | No | Who runs it: government (national), lgu (city), private (foundation/company), university | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only that the list is "curated" and filtered; it says nothing about result size, pagination behavior, or whether a total count is returned. With annotations carrying the main burden, a 3 is appropriate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste: purpose and filters first, the sibling routing second. Nothing is repeated from the title and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Annotations cover the safety/idempotency profile and the schema fully documents all six parameters, so the description only needed to state scope and routing, which it does. The one gap is pagination: with a default limit of 20 and a max of 50 plus an offset, an agent isn't told whether it must page through results or whether a total count comes back, and there is no output schema to answer that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with enums documented for level, provider_type and response_format, so the schema does the heavy lifting. The description echoes three of the six filter names (level, provider type, region) but adds no semantics beyond the schema and omits mention of limit/offset/pagination. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ("browse the full curated list of Philippine scholarships") plus the filter dimensions available, and explicitly names the sibling it is not (ph_search_scholarships). An agent can distinguish it from ph_get_scholarship and ph_search_scholarships without opening a schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit routing rule: use ph_search_scholarships when you have a specific question, implying this tool is for unfiltered/exploratory browsing. The exclusion criterion ("specific question") is slightly loose rather than a crisp condition, and it doesn't mention ph_get_scholarship for a known scholarship, but the primary alternative is covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Philippine universities and colleges with code, type (e.g. State, Private), city and region. Filter by region code from ph_list_regions (e.g. "R10") and by type (e.g. "State"). Partial coverage, not every school.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | School type to match, e.g. "State" or "Private" | |
| limit | No | Maximum number of schools | |
| offset | No | Number of schools to skip, for pagination | |
| region | No | Region code, e.g. "NCR" or "R10" | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
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 without the description. The one genuinely additive behavioral fact is "Partial coverage, not every school", which meaningfully warns the agent not to treat empty results as non-existence. Beyond that it says nothing about default page size or the cost of paginating, which is left entirely to the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool returns, then filters, then the coverage caveat — a sensible ordering with no filler. It could be marginally tighter since the type/region examples duplicate the schema, but nothing is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description correctly compensates by listing the returned fields (code, type, city, region). Pagination and result caps live in the schema, and the "partial coverage" caveat sets expectations. For a simple read-only list tool this is close to complete; only the ordering or total-count behavior of results is unstated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all five parameters including examples ("State", "R10") and pagination defaults. The description restates the same region and type examples almost verbatim, adding little new meaning. Baseline 3 applies when the schema carries the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (Philippine universities and colleges) and enumerates the fields returned (code, type, city, region), so the agent knows exactly what a call yields. It is clear and specific, though it lacks an explicit verb like "list" and doesn't distinguish itself from any sibling beyond citing ph_list_regions as a code source — a minor gap given there is no competing school-listing tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Guidance is implicit but traceable: "Filter by region code from ph_list_regions (e.g. 'R10')" tells the agent to source valid codes from a sibling tool first, and "Partial coverage, not every school" warns results are incomplete. What is missing is any when-not guidance — e.g. whether to paginate through all results or when a narrower type filter is preferred over a broad listing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find Philippine scholarships and student financial aid that match a question, in English or Taglish (e.g. "incoming college, BS Engineering", "anak ng OFW", "TESDA courses", "grad school science"). Searches a curated list of programs (DOST, CHED, TESDA, OWWA, LGUs, foundations, universities) where every fact was checked against the official page. Returns the best matches with summary, period and official URL. Use ph_get_scholarship for full eligibility and benefits. Never state amounts or deadlines the results do not contain.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | Only return programs for this level (detected from the query if omitted) | |
| limit | No | Maximum number of matches | |
| query | Yes | What the student is looking for, in English or Taglish | |
| response_format | No | 'markdown' for readable text (default), 'json' for structured data | markdown |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only/idempotent/closed-world profile. The description adds material context beyond that: the corpus is curated and fact-checked against official pages, and it states the return shape (summary, period, official URL) plus a grounding constraint ('Never state amounts or deadlines the results do not contain'). It does not cover empty-result or low-confidence-match behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with the action and scope first, examples second, and the escalation path plus grounding rule last. No filler and nothing repeated from the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the return-value burden and discharges it by naming summary, period and official URL. For a 4-parameter read-only search, the only remaining item an agent might want is behavior on zero matches, which is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description contributes beyond the schema by modeling how the query parameter should look in practice ('incoming college, BS Engineering', 'anak ng OFW', 'TESDA courses'), which shows Taglish phrasing and colloquial terms the schema's 'English or Taglish' line does not illustrate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Find Philippine scholarships and student financial aid') plus the matching criterion ('that match a question, in English or Taglish'). The parenthetical program list (DOST, CHED, TESDA, OWWA, LGUs, foundations, universities) distinguishes it from ph_list_scholarships, which enumerates rather than matches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent to ph_get_scholarship 'for full eligibility and benefits', which is a clear alternative-selection rule. It gives concrete example queries to anchor when this tool fires, but never contrasts itself with ph_list_scholarships, so the sibling boundary for enumeration vs search is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0ph_convert_currencyph_get_scholarshipph_get_weatherph_list_holidaysph_list_regionsph_list_scholarshipsph_list_schoolsph_search_scholarshipsScored across 8 tools
Each tool targets a distinct resource+action (currency conversion, weather, holidays, regions, schools, and three scholarship operations) with no true duplicates. The potential list_scholarships vs search_scholarships overlap is explicitly resolved in the descriptions, which tell the agent which to use when.
All eight tools follow a uniform ph_verb_noun snake_case pattern (ph_convert_currency, ph_get_weather, ph_list_regions, ph_search_scholarships). The shared ph_ prefix reinforces the server's domain scope without breaking the verb_noun convention.
Eight tools sit comfortably in the well-scoped 3-15 range, and each maps to a distinct Philippine data need. No tool feels like filler or a redundant variant.
Scholarships get full lifecycle coverage (list, search, get) and the other domains have sensible entry points. Minor gaps remain: schools and regions are list-only with no detail lookup, weather is current-only with no forecast, and currency has no supported-currency listing, but these are workable around.
Read-only airport delay, weather, and 24h forecast tools for AI assistants. Airport-level only.
Korean company facts in English for AI agents: ~830 KOSPI-listed companies (DART profiles, KRW financials, recent filings) and ~110,000 corporate public procurement suppliers (12-month KONEPS contract awards), plus live National Tax Service business status checks. 4 tools, keyless, read-only.
Pay-per-call tools for AI assistants: code, data, finance, spreadsheets, media, web, time.
Real-time data API for AI Agents: stocks, weather, forex, logistics, search, scrape, news, IP.
