Yaizu Smart City MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
There is moderate overlap between tools like execute_api_endpoint and execute_yaizu_api, which both execute API calls but with different approaches, potentially causing confusion. However, other tools like scrape_api_docs and search_api_docs have distinct purposes, and descriptions help clarify the differences. Some tools, such as get_api_details and list_saved_apis, serve related but separate functions, reducing ambiguity.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., execute_api_endpoint, generate_api_command, get_api_details), which is predictable and readable. There is a minor deviation with execute_yaizu_api, which uses a specific name instead of a generic verb, but it still fits the overall style. The naming is largely uniform, aiding in tool identification.
Tool Count5/5
With 8 tools, the count is well-scoped for a smart city API server, covering execution, documentation management, and information retrieval without being overwhelming. Each tool appears to serve a specific purpose in the domain, such as scraping, searching, and executing APIs, making the set appropriately sized for the server's functionality.
Completeness4/5
The tool set provides good coverage for interacting with Yaizu's FIWARE NGSIv2 API, including execution, documentation scraping, searching, and listing. Minor gaps exist, such as the lack of tools for updating or deleting entities, which might limit full CRUD operations, but core workflows like data retrieval and documentation management are well-supported, allowing agents to work effectively.
Average 3.2/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
- No commit activity data available
- 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 full burden for behavioral disclosure. The description only states what the tool does functionally ('get detailed information') without any behavioral context about permissions needed, rate limits, what format the details come in, whether this is a read-only operation, or any error conditions. For a tool with no annotation coverage, this is insufficient behavioral transparency.
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 appropriately concise with a clear purpose statement followed by Args and Returns sections. The structure is front-loaded with the main functionality first. While efficient, the Args section could be slightly more detailed given the 0% schema coverage, but overall it's well-structured without wasted words.
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 an output schema (which handles return value documentation) and only 1 parameter with 0% schema coverage, the description provides the minimum viable information about what the tool does and the parameter semantics. However, for a tool with no annotations and multiple sibling tools that seem related, the description should do more to differentiate this tool's specific role and provide behavioral context.
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?
With 0% schema description coverage and only 1 parameter, the description provides crucial semantic information about the 'api_name' parameter, explaining it accepts 'API名またはファイル名（拡張子なし）' - 'API name or filename (without extension)'. This adds meaningful context beyond the bare schema, though it could be more specific about what constitutes valid API names versus filenames.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the purpose ('特定のAPIの詳細情報を取得します' - 'Get detailed information for a specific API') which is a clear verb+resource combination. However, it doesn't distinguish this tool from its siblings like 'get_sample_endpoints' or 'search_api_docs' - all of which seem to retrieve API-related information. The purpose is understandable but lacks sibling differentiation.
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. With siblings like 'list_saved_apis', 'search_api_docs', and 'get_sample_endpoints', there's no indication of when this specific 'get_api_details' tool is appropriate versus those other information-retrieval tools. The description is purely functional without contextual guidance.
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 states the tool searches saved API documentation by keyword across API name, description, and category, but doesn't mention critical aspects like whether it's read-only (implied but not explicit), how results are formatted, if there are rate limits, or authentication requirements. For a search tool with zero annotation coverage, this leaves significant gaps.
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 concise and well-structured: a clear purpose statement followed by Args and Returns sections. It avoids unnecessary fluff, and every sentence adds value. However, the Japanese text might be slightly less accessible in some contexts, but it's still efficient.
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 an output schema (Returns: str), the description doesn't need to explain return values in detail. However, with no annotations and incomplete parameter guidance, it's adequate but has clear gaps. The description covers the basic functionality but lacks depth on usage context and behavioral traits, making it minimally viable.
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 description adds some semantic context: it explains that 'keyword' searches across API name, description, and category. However, with 0% schema description coverage (the schema only provides title and type), the description compensates partially but doesn't detail syntax, format, or examples. Since there's only one parameter, the baseline is higher, but more specifics would improve this.
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 purpose: '保存済みのAPIドキュメントから特定のキーワードでAPIを検索します' (Search APIs from saved API documentation using specific keywords). It specifies the verb (search), resource (saved API documentation), and scope (by keyword). However, it doesn't explicitly differentiate from siblings like 'list_saved_apis' or 'get_api_details', which would require a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. With siblings like 'list_saved_apis' (likely lists all APIs) and 'get_api_details' (likely gets details for a specific API), there's no indication of when keyword searching is preferred over other methods. It mentions what the tool does but not when it's appropriate.
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 states the tool retrieves data and automatically configures endpoints, but lacks details on authentication requirements, rate limits, error handling, or whether it's read-only (though implied by '取得します'). For a tool interacting with an external API, this is a significant gap in transparency.
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 appropriately sized and front-loaded, starting with the core purpose. The Args and Returns sections are structured clearly, though the Japanese text might add minor complexity for non-Japanese agents. Every sentence adds value, with no redundant information.
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's complexity (API interaction with 3 parameters) and no annotations, the description is moderately complete. It covers purpose and parameters well, and an output schema exists (implied by 'Returns: str: APIレスポンス'), so return values needn't be detailed. However, it lacks behavioral context like auth or error handling, which is a gap for an API 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?
The description adds meaningful semantics beyond the input schema, which has 0% description coverage. It explains 'entity_type' with examples (Aed, EvacuationShelter, DisasterMail), clarifies 'params' as JSON string for additional query parameters, and specifies 'limit' range (1-1000) and default (10). This compensates well for the schema's lack of descriptions, though it doesn't detail the structure of 'params' JSON.
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 purpose: '焼津市のFIWARE NGSIv2 APIからエンティティデータを取得します' (retrieves entity data from Yaizu City's FIWARE NGSIv2 API). It specifies the verb '取得します' (retrieves) and resource 'エンティティデータ' (entity data). However, it doesn't explicitly differentiate from sibling tools like 'execute_api_endpoint' or 'get_api_details', which likely serve related but distinct purposes.
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 mentions 'APIカタログの情報を基に適切なエンドポイント設定を自動で行います' (automatically configures appropriate endpoints based on API catalog information), which implies some context, but doesn't specify when to choose this over siblings like 'execute_api_endpoint' or 'search_api_docs'. No explicit when/when-not statements or named alternatives are included.
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 states the tool returns 'a list of endpoint examples' as a string, which is minimal behavioral info. It doesn't describe whether this is a read-only operation, if it requires authentication, rate limits, or what the examples include (e.g., sample URLs, methods). For a tool with zero annotation coverage, this is insufficient.
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 appropriately sized and front-loaded: the first sentence states the purpose clearly, and the second specifies the return type. There's no wasted text, and it's structured efficiently. However, it could be slightly more concise by combining sentences, but it's already minimal.
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 0 parameters, 100% schema coverage, and an output schema exists (implied by 'Returns: str'), the description is somewhat complete but lacks depth. It states the purpose and return type, but for a tool with no annotations, it should ideally include more behavioral context (e.g., what the examples look like, if it's a static list). The output schema handles return values, so that's covered, but overall completeness is minimal.
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 schema description coverage is 100% (though empty). The description doesn't need to add parameter semantics, so it meets the baseline. It correctly doesn't mention any parameters, which aligns with the schema. No extra value is added, but none is required for a parameterless tool.
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 purpose: 'provide examples of major endpoints for the Yaizu City Smart City API.' It specifies the verb ('provide') and resource ('endpoint examples'), though it doesn't explicitly differentiate from siblings like 'get_api_details' or 'list_saved_apis' which might also return endpoint information. The purpose is clear but lacks sibling distinction.
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 offers no guidance on when to use this tool versus alternatives. It doesn't mention siblings like 'get_api_details' (which might provide detailed endpoint info) or 'execute_api_endpoint' (which might use endpoints), nor does it specify prerequisites or contexts for usage. There's no explicit or implied usage guidance beyond the basic purpose.
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 states the tool displays a list but doesn't describe format, pagination, sorting, or error conditions. The mention of return type ('str: ドキュメント一覧') is minimal and doesn't clarify what the string contains (e.g., JSON, plain text). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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 brief and front-loaded with the core purpose in the first sentence. The second sentence about returns is minimal but could be more integrated. There's no wasted text, though the structure could be slightly tighter by combining the two sentences for better flow.
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's simplicity (0 parameters, output schema exists), the description is adequate but not complete. It states what the tool does but lacks context on usage versus siblings and behavioral details. The output schema existence means the description doesn't need to detail return values, but it still misses guidance and transparency elements that would make it more helpful for an agent.
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 input schema has 100% description coverage (though empty). The description doesn't need to explain parameters, so it appropriately avoids this. A baseline of 4 is given since no parameter information is required, and the description doesn't introduce confusion about inputs.
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 purpose: '保存済みのAPIドキュメント一覧を表示します' (displays a list of saved API documents). This specifies both the verb (display/list) and resource (saved API documents). However, it doesn't explicitly differentiate from sibling tools like 'search_api_docs' or 'get_api_details', which prevents a perfect score.
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. With sibling tools like 'search_api_docs' and 'get_api_details' available, there's no indication of when this listing function is preferred over searching or getting details, nor any mention of prerequisites or exclusions.
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 provided, the description carries the full burden of behavioral disclosure. It states the tool generates API commands but doesn't specify whether this is a read-only operation, whether it requires authentication, what happens if the entity_type is invalid, or any rate limits. The description is functional but lacks important behavioral context.
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 efficiently structured with a clear purpose statement followed by Args and Returns sections. Every sentence earns its place, and the information is front-loaded with no wasted words. The bilingual format (Japanese description with English Args/Returns) is compact.
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 single-parameter tool with an output schema (which handles return value documentation), the description is minimally adequate. However, given the sibling tools and lack of annotations, it should provide more context about when this generation is useful versus directly executing or getting API details.
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?
With only 1 parameter and 0% schema description coverage, the description compensates well by explaining what entity_type represents ('entity type' with examples like 'Aed, EvacuationShelter') and clarifying that it's used to generate appropriate API commands based on API catalog information. This adds meaningful context beyond the bare schema.
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 purpose: 'generate API execution commands for specified entity types' and 'proposes appropriate parameters based on API catalog information'. It specifies the verb (generate) and resource (API commands), but doesn't explicitly differentiate from sibling tools like execute_api_endpoint or get_api_details.
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 like execute_api_endpoint (which likely executes commands) or get_api_details (which likely provides API information). There's no mention of prerequisites, use cases, or exclusions.
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 provided, the description carries the full burden. It discloses that authentication is handled via .env files and that it saves the scraped data, which are useful behavioral traits. However, it lacks details on rate limits, error handling, or what 'saves' entails (e.g., file location, overwrite behavior).
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 brief and front-loaded with the main action in the first sentence. The second sentence adds useful authentication context, and the 'Returns' section clarifies output. It could be slightly more structured but avoids waste.
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 no annotations, 0 parameters, and an output schema (implied by 'Returns'), the description is minimally adequate. It covers the action and authentication, but lacks context on sibling tool differentiation and detailed behavioral aspects like what 'saves' means, leaving some gaps.
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 has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information.
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 scrapes API documentation from a specific source (Yaizu City API catalog) and saves it, using the verb 'scrape' and resource 'API documentation'. However, it doesn't explicitly differentiate from sibling tools like 'search_api_docs' or 'get_api_details', which might have overlapping functionality.
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 like 'search_api_docs' or 'get_api_details'. It mentions authentication is handled automatically, but doesn't specify prerequisites, timing, or exclusions for usage.
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 full burden. It mentions the tool is deprecated but doesn't disclose critical behavioral traits like authentication requirements, error handling, rate limits, or whether it performs destructive operations (e.g., DELETE method). The description only covers basic input/output, leaving significant gaps for a generic API 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 well-structured and front-loaded with the deprecation warning, followed by clear sections for Args and Returns. Every sentence adds value: the deprecation notice, the alternative recommendation, and parameter explanations. No wasted words, making it efficient for an agent 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?
Given the tool's complexity (generic API execution with 3 parameters), no annotations, and an output schema exists (specifying str return), the description is partially complete. It covers purpose, usage guidelines, and basic parameter semantics but lacks behavioral context (e.g., auth, errors) and detailed parameter guidance, making it adequate but with clear gaps for safe and effective use.
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 0%, so the description must compensate. It adds meaning by explaining 'endpoint_url' as the API endpoint URL, 'method' as HTTP methods with examples, and 'params' as query parameters or JSON body in string form. However, it doesn't clarify format details (e.g., URL encoding, JSON structure) or constraints, partially compensating but not fully bridging the coverage gap.
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 this is a 'generic endpoint execution tool' that makes API calls, specifying it takes an endpoint URL, HTTP method, and parameters. It distinguishes itself from siblings by mentioning 'execute_yaizu_api()' as the recommended alternative for new code. However, it doesn't specify what type of API it interacts with (e.g., REST, internal), making it slightly less specific than a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: it's deprecated and should not be used for new code, with 'execute_yaizu_api()' named as the alternative. It also implies usage context by stating it's kept for compatibility, helping the agent understand when to avoid this tool versus when it might be necessary for legacy systems.
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:

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

Score Badge

Copy to your README.md:

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

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