Ginta

Let a site call an API with a secret

manage_connections

Destructive

Use when the site's JavaScript must call an outside API: save a connection (name, https base URL, which secret, how it's sent), and the page calls fetch("/_ginta/api//"); Ginta adds the key and forwards to that base URL only. list shows connections and this month's calls.

Input Schema

Name	Required	Description
`auth`	No	How the key is sent: "bearer" (Authorization: Bearer, default), "header" (auth_name = the header, e.g. X-API-Key) or "query" (auth_name = the parameter, e.g. appid).
`name`	No	Connection name, e.g. "weather" (save, delete).
`action`	Yes	What to do: list the connections, save (add or change) one, or delete one.
`secret`	No	Name of the secret to attach (from manage_secrets). Omit for public APIs.
`methods`	No	Allowed methods (default GET and POST).
`site_id`	Yes	The site id: the first part of the site URL, e.g. "bella-roma" for https://bella-roma.ginta.page (see list_sites).
`base_url`	No	The API's https base URL, e.g. "https://api.openweathermap.org/data/2.5".
`auth_name`	No	Header or query parameter name for auth header/query.

Output Schema

Name	Required	Description
`name`	No	save/delete: the connection's name.
`text`	Yes	The answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).
`site_id`	Yes	The site id.
`connections`	No	list: the connections.
`usage_this_month`	No	list: calls this month.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

addedOutput schema / properties / text

Added value: +{
+  "description": "The answer in words, the same as the text content: read it (for get_guide the whole guide, for get_site the files' contents).",
+  "type": "string"
+}

changedOutput schema / required

Previous value: -[
-  "site_id"
-]New value: +[
+  "site_id",
+  "text"
+]

First observedOct 15, 2026

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is supplied. The description adds genuinely non-obvious behavior: Ginta injects the key so the page never sees it, and forwarding is restricted to that base URL only — a meaningful security boundary. It still does not say what deletion removes or whether it affects live traffic.

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 guidance is front-loaded in the opening clause and the total length is small. The single dense sentence with embedded fetch() syntax is slightly hard to parse, and the escaped quotes add noise, but no sentence is wasted.

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?

An output schema exists, so return values need not be explained, and the list action's output is still helpfully summarized (connections plus this month's calls). With 8 parameters and three actions, the only real omission is delete semantics, which the action enum's own description partially covers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents every parameter including the auth enum and methods default. The description only echoes a subset (name, base URL, secret, how it's sent) and adds the useful detail that the connection name becomes the URL path segment. That is baseline-level added meaning, not a substitute for schema detail.

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 names a concrete resource and operation (save a connection with name, https base URL, secret, and auth style) and explains the resulting proxy endpoint pattern. It clearly covers save and list, but never describes what the 'delete' action does, so the multi-action scope is only partially stated.

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?

"Use when the site's JavaScript must call an outside API" gives an explicit triggering condition, which is strong. However, it offers no exclusions or sibling comparison (e.g. manage_secrets is only referenced indirectly through the secret parameter), and the delete action's use case is unaddressed.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Ginta tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?