Enables automated retrieval and parsing of Hetzner Cloud invoices, including fetching invoice PDFs, extracting structured data, and accessing line-item details.
Provides programmatic access to the OpenCollective GraphQL API v2 to manage collectives, search accounts, process expenses, query ledger transactions, and handle member information.
Click on "Install 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., "@OpenCollective MCP Server Submit the latest Hetzner invoice as an expense to my collective"
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.
A Model Context Protocol server that gives AI agents programmatic access to OpenCollective, Hetzner Cloud, and Cloudflare — enabling automated bookkeeping, collective management, and invoice handling without manual intervention.
This MCP server exposes 22 tools that let AI agents interact with:
OpenCollective GraphQL API v2 — Manage collectives, submit expenses, process payments, query transactions, and handle members
Hetzner Cloud invoices — Automatically fetch, parse, and reconcile hosting invoices
Cloudflare billing — Track CDN and hosting costs via the billing history API
If you run an OpenCollective-backed project with infrastructure on Hetzner, you face a tedious monthly ritual:
Log into Hetzner → navigate to invoices → download the PDF
Manually extract the amount, date, and line items
Log into OpenCollective → create a new expense → copy-paste the data
Submit and wait for approval
Repeat every month. Forever.
This MCP automates it.
Related MCP server: QuickFile MCP Server
Open collective maintainers who want to automate expense workflows
DevOps engineers running infrastructure on Hetzner who track costs via OpenCollective
AI developers building agents that need to manage budgets, expenses, or financial reporting
Bookkeepers tired of copy-pasting invoice data between systems
Tool | What it does |
| Get detailed info about any collective (balance, stats, social links) |
| Search across all OpenCollective accounts |
| Get the authenticated user's account |
| Update collective profile (name, description, tags, currency) |
| List members, backers, and their donation totals |
| Query expenses with rich filters (status, type, date, tags) |
| Get full expense details by ID |
| Submit new expenses (INVOICE, RECEIPT, GRANT, etc.) |
| Modify existing expenses |
| Remove expenses |
| Approve, reject, pay, hold, or release expenses |
| Query the ledger (credits/debits, linked expenses) |
| Escape hatch for any GraphQL operation |
Tool | What it does |
| List all invoices (paginated) |
| Get a specific invoice by ID |
| Fetch the most recent invoice |
| Download invoice as PDF (base64) |
| Extract structured data from invoice PDF |
| Get line-item breakdown from usage portal |
Tool | What it does |
| List billing history (paginated). Auto-converts USD to EUR using historical ECB rates |
| Get a specific billing item by ID. Includes EUR conversion |
| Fetch the most recent billing item. Returns |
# 1. Fetch the latest Hetzner invoice
invoice = hetzner_get_latest_invoice()
# 2. Submit it as an expense to your collective
oc_create_expense(
account_slug="my-collective",
description=f"Hetzner Cloud - {invoice['date']}",
expense_type="INVOICE",
payee_slug="my-org",
items=[{
"description": f"Cloud services - {invoice['date']}",
"amount_cents": invoice['amount_cents'],
"currency": "EUR"
}],
tags=["hetzner", "hosting"]
)# For Cloudflare (automatically converts USD to EUR)
invoice = cloudflare_get_latest_invoice()
oc_create_expense(
account_slug="my-collective",
description=f"Cloudflare - {invoice['date']}",
expense_type="INVOICE",
payee_slug="my-org",
items=[{
"description": f"Cloudflare services - {invoice['date']}",
"amount_cents": invoice['amount_cents_eur'], # Already converted!
"currency": "EUR"
}],
tags=["cloudflare", "hosting", "cdn"]
)That's it. One agent prompt = one booked expense.
Not a replacement for human judgment — Expenses still need approval based on your collective's policies
Not a financial advisory tool — It moves data, not money; you control the payouts
Not limited to Hetzner — The oc_execute_graphql tool lets you run any OpenCollective operation, so you can manage Stripe payouts, Wise transfers, or budget forecasting
Not a GUI — It's a backend for AI agents; use the OpenCollective dashboard for manual tasks
git clone https://github.com/your-org/opencollective-mcp.git
cd opencollective-mcp
pip install -e .Copy .env.example to .env and fill in:
cp .env.example .env
# Edit .env with your credentialsVariable | Required for | How to get it |
| Write operations | OpenCollective dashboard → For Developers → Personal Tokens |
| Hetzner invoice tools | Your Hetzner account email |
| Hetzner invoice tools | Your Hetzner password |
| Hetzner invoice tools (if 2FA) | Shown when you enable 2FA |
| Cloudflare billing tools | Cloudflare dashboard → My Profile → API Tokens → Create Token with "Billing:Read" permission |
# Direct
python -m opencollective_mcp
# Or via installed script
opencollective-mcpAdd to your ~/.claude.json:
{
"mcpServers": {
"opencollective": {
"command": "python",
"args": ["-m", "opencollective_mcp"],
"env": {
"OPENCOLLECTIVE_TOKEN": "your-token",
"HETZNER_ACCOUNT_EMAIL": "you@example.com",
"HETZNER_ACCOUNT_PASSWORD": "your-password",
"CLOUDFLARE_API_TOKEN": "your-cloudflare-token"
}
}
}
}Because infrastructure costs should be visible, automated, and auditable — exactly what OpenCollective provides for open source projects.
We built this to solve our own bookkeeping pain: tracking Hetzner hosting costs for Going Dark and automatically submitting them as expenses each month. Now our AI agent does it.
If you run a collective with cloud infrastructure, this saves you 15–30 minutes every month — and eliminates human error from manual data entry.
Apache License 2.0
Built with FastMCP, httpx, and Playwright.
Get details of a specific Cloudflare billing item by ID.
When convert_to_eur is True (default), automatically converts USD amounts to EUR using historical exchange rates from the European Central Bank.
Returns invoice with:
amount: Original amount (usually USD)
currency: Original currency code
amount_eur: Converted EUR amount (when conversion enabled)
amount_cents_eur: EUR amount in cents (for OpenCollective)
exchange_rate: Rate used for conversion
rate_date: Date the exchange rate was fetched
Requires CLOUDFLARE_API_TOKEN to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate read-only and idempotent. Description adds authentication requirement, conversion behavior, and output fields, providing useful behavioral context beyond annotations.
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?
Concise and well-organized: starts with purpose, then conversion, output format, and auth requirement. No wasted sentences, but could be slightly more structured.
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?
Given 2 simple params and output schema present, description covers purpose, usage, conversion, output fields, and auth. Complete for this straightforward 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 has 0% description coverage, but description explains invoice_id purpose, convert_to_eur default and effect, and lists output fields, compensating for schema gaps.
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?
Description clearly states 'Get details of a specific Cloudflare billing item by ID', specifying verb, resource, and how to identify the item. Distinguishes from siblings like cloudflare_get_latest_invoice and cloudflare_list_invoices.
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?
Implies usage when you have an invoice ID, and mentions required env var CLOUDFLARE_API_TOKEN. No explicit exclusions, but context signals alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent Cloudflare billing item.
Fetches the latest billing item with cost and date. When convert_to_eur is True (default), automatically converts USD amounts to EUR using historical exchange rates from the European Central Bank.
Returns invoice with:
amount: Original amount (usually USD)
currency: Original currency code
amount_eur: Converted EUR amount (when conversion enabled)
amount_cents_eur: EUR amount in cents (ready for OpenCollective)
exchange_rate: Rate used for conversion
rate_date: Date the exchange rate was fetched
Requires CLOUDFLARE_API_TOKEN to be set.
Useful for automated monthly bookkeeping: fetch the latest Cloudflare bill and then use oc_create_expense to submit it to OpenCollective.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds value beyond readOnlyHint annotation by detailing currency conversion behavior and return fields (amount, currency, amount_eur, etc.). No contradictions with annotations.
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?
Well-structured with clear front-loading of purpose. Each sentence adds value, though slightly verbose with return field listing; could be more concise.
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?
Despite missing output schema in input, description explicitly lists return fields. Annotations cover safety. Guidelines and parameter semantics are complete for this tool's 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?
While schema already has description for convert_to_eur, the tool description adds context about historical exchange rates and shows how parameter affects output (amount_eur, exchange_rate). Schema coverage is actually present despite context signal claiming 0%.
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 clearly states 'Get the most recent Cloudflare billing item' and specifies verb and resource. It distinguishes from siblings like cloudflare_get_invoice and cloudflare_list_invoices by focusing on the latest item.
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?
Provides context for automated monthly bookkeeping and suggests using oc_create_expense next. Mentions requirement for CLOUDFLARE_API_TOKEN. Does not explicitly say when not to use or compare with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List billing history from Cloudflare.
Returns billing items with cost and date. When convert_to_eur is True (default), automatically converts USD amounts to EUR using historical exchange rates from the European Central Bank (via Frankfurter API).
Each invoice includes:
amount: Original amount (usually USD)
currency: Original currency code
amount_eur: Converted EUR amount (when conversion enabled)
amount_cents_eur: EUR amount in cents (for OpenCollective)
exchange_rate: Rate used for conversion
rate_date: Date the exchange rate was fetched
Requires CLOUDFLARE_API_TOKEN to be set. Uses the Cloudflare API (deprecated but functional /user/billing/history endpoint).
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial behavioral context: it uses a deprecated Cloudflare API endpoint, automatically converts USD to EUR using ECB rates via Frankfurter API, and lists each returned field. This fully informs an agent of side effects and data transformations.
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?
The description is concise at 12 lines, front-loaded with the core purpose, and structured with a bulleted list of returned fields. Every sentence adds value—no redundancy or tautology. This is an efficient, well-organized description.
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?
Given the tool's low complexity, detailed annotations, and presence of an output schema, the description is complete. It covers the main behavior (listing invoices), conversion logic, returned fields, token requirement, and endpoint deprecation. No gaps for an agent to operate 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?
With 0% schema description coverage, the description must explain parameters. It clearly explains the convert_to_eur parameter (default behavior, conversion source). However, it provides no explanation for page and per_page parameters beyond what the schema names imply. Pagination details are missing, so the description only partially compensates.
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 starts with 'List billing history from Cloudflare', a specific verb and resource. It clearly distinguishes from sibling tools like cloudflare_get_invoice and cloudflare_get_latest_invoice by indicating it lists all invoices. The summary of returned fields further clarifies the tool's scope.
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 description states when to use the tool (list billing history) and includes prerequisites (CLOUDFLARE_API_TOKEN). It does not explicitly state when not to use or compare with alternatives, but the sibling tool names provide implicit guidance. Lack of explicit exclusions prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific Hetzner Cloud invoice by ID.
Requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false, indicating a safe read operation. The description adds a behavioral constraint (requires environment variables) beyond the annotations, which is useful. No contradictions found.
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?
The description consists of two short, front-loaded sentences. The first sentence states the core purpose clearly, and the second sentence adds a critical prerequisite. No verbosity or repetition; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, read-only, output schema exists), the description adequately covers the essential information. It explains the purpose and required setup. It does not cover error handling or edge cases, but for a simple get-by-id operation, it is nearly complete.
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?
The input schema has one required parameter 'invoice_id' with description 'Invoice ID'. The tool description does not elaborate on the parameter's format, source, or semantics. Given that schema description coverage is 0% (the schema description is minimal and considered insufficient), the description fails to add meaningful information.
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 'Get details of a specific Hetzner Cloud invoice by ID' clearly states the verb (get details), resource (Hetzner Cloud invoice), and identifier (by ID). It distinguishes from siblings like 'hetzner_list_invoices' and 'hetzner_get_invoice_pdf', but 'hetzner_get_invoice_details' could be a direct duplicate, which slightly reduces clarity.
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 description mentions prerequisites (HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD must be set), which is helpful. However, it does not guide when to use this tool versus alternatives like 'hetzner_list_invoices' or 'hetzner_get_invoice_pdf', nor does it explain typical workflow (e.g., first list, then get).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed invoice information from Hetzner usage portal.
Fetches invoice line items as CSV from usage.hetzner.com. Requires HETZNER_ACCOUNT_EMAIL, HETZNER_ACCOUNT_PASSWORD, and HETZNER_CUSTOMER_NUMBER to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide safety profile (readOnly, idempotent, non-destructive). The description adds value by specifying authentication requirements (environment variables) and data source (usage.hetzner.com, CSV format), which are beyond annotation scope.
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?
The description is only two sentences: one for core functionality and one for requirements. It is front-loaded and contains no extraneous information.
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?
Given the simplicity of the tool (one key parameter) and the existence of an output schema, the description covers the main behavioral aspects and prerequisites. It could be slightly improved by explaining the parameter, but overall it is fairly complete.
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?
The required parameter 'usage_id' has a clear description in the schema itself, but the tool description does not mention it at all. Schema description coverage is 0%, and the description fails to add any explanatory context 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 clearly states that it retrieves detailed invoice information, specifically line items as CSV from usage.hetzner.com. This distinguishes it from sibling tools like hetzner_get_invoice (likely summary) and hetzner_get_invoice_pdf (PDF format).
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 description mentions required environment variables as prerequisites but does not explicitly state when to use this tool versus alternatives like hetzner_get_invoice or when line items are needed. Usage context is implied but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download a Hetzner invoice as PDF.
Returns the PDF content as base64-encoded string. Requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, idempotent, non-destructive. The description adds the return format (base64 PDF) and credential requirements, providing useful behavioral context beyond annotations. No contradiction.
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 sentences with no fluff: purpose, return format, prerequisites. Front-loaded and efficient. Every sentence 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?
Given the tool's simplicity and the existence of an output schema, the description covers purpose, return format, and prerequisites. It lacks error or limitation details but is sufficient for a straightforward 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?
The input schema already describes the invoice_id parameter. The tool description does not add any additional meaning or context for the parameter, so score at baseline 3.
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 clearly states the tool downloads a Hetzner invoice as PDF, with a specific verb and resource. It distinguishes itself from siblings like hetzner_get_invoice (likely metadata) and hetzner_parse_invoice_pdf (parsing) by focusing on PDF download.
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 description implies usage when a PDF is needed, but provides no explicit comparison to alternatives or when not to use. It mentions prerequisites (credentials) but lacks guidance on context or exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the most recent Hetzner Cloud invoice.
Fetches the first page of invoices and returns the latest one. Requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD to be set.
Useful for automated monthly bookkeeping: fetch the latest Hetzner invoice and then use oc_create_expense to submit it to OpenCollective.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint true and destructiveHint false. The description adds value by explaining the inner mechanism (fetches first page of invoices) and credential requirements. No contradictions with annotations.
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?
The description is concise with no wasted words. It front-loads the core action and adds necessary context in a structured manner. Every sentence adds value.
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?
The description fully covers the tool's purpose, method, requirements, and a suggested use case. With an output schema present, the lack of return value details is acceptable. For a simple tool, it is complete.
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 0% (no description for the 'ctx' parameter). The description does not mention or explain the parameter at all. For a low-coverage schema, the description should compensate, but it fails to do so.
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 clearly states 'Get the most recent Hetzner Cloud invoice' and explains it fetches the first page and returns the latest one. It distinguishes from siblings like 'hetzner_list_invoices' and 'hetzner_get_invoice' by focusing on the latest invoice.
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 description provides good context: it requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD, and suggests using it for automated monthly bookkeeping followed by 'oc_create_expense'. However, it does not explicitly state when not to use this tool or compare it to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List invoices from Hetzner Cloud.
Returns paginated invoice data. Requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD to be set. Uses browser automation to fetch invoices from accounts.hetzner.com.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare read-only and idempotent hints. The description adds that it uses browser automation, a behavioral trait not in annotations, and returns paginated data. This enriches understanding beyond structured fields.
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 sentences efficiently convey purpose, output type, and requirements without extraneous information. Structured front-loaded with main action first.
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 simple list tool with annotations and output schema present, the description provides necessary context: what it does, prerequisites, automation method, and pagination. No gaps identified.
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?
Input schema already describes both parameters (page, per_page) with clear descriptions. The tool description does not add any additional semantic information about parameters, so baseline score is appropriate.
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?
Clearly states the tool lists invoices from Hetzner Cloud, distinguishing it from sibling tools like hetzner_get_invoice. The description is specific about the resource (invoices) and action (list).
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?
Specifies required environment variables (HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD) and mentions browser automation, providing context for when to use. However, it does not explicitly guide against misuse or compare with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Download and parse a Hetzner invoice PDF to JSON.
Extracts invoice data like invoice number, date, amount, net, VAT, etc. Requires HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, idempotent, and non-destructive behavior. The description adds the constraint that credentials must be set, which is a behavioral requirement not captured in annotations. No other behavioral traits (e.g., error handling, performance) are disclosed.
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?
The description is concise with two sentences: first covers the main purpose, second adds extracted fields and prerequisites. It is front-loaded and contains no unnecessary words or repetition.
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?
Given the simple parameter set, annotations covering safety, and the presence of an output schema, the description is complete. It states the input needed (invoice_id and env vars) and the output (parsed JSON with specific fields). No gaps are apparent.
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?
The input schema already provides a clear description for the required 'invoice_id' parameter. The tool description does not add any further meaning or usage guidance for the parameter, so baseline score of 3 applies due to high schema coverage.
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 clearly states the tool downloads and parses a Hetzner invoice PDF to JSON, specifying the verb action and resource. It distinguishes from sibling tools like hetzner_get_invoice_pdf which likely returns raw PDF, and provides the output format.
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 description mentions required environment variables (HETZNER_ACCOUNT_EMAIL and HETZNER_ACCOUNT_PASSWORD), which is a useful prerequisite. However, it does not explicitly state when to use this tool over alternatives like hetzner_get_invoice_details or hetzner_get_invoice, missing direct usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a new expense to an OpenCollective collective.
Supports INVOICE, RECEIPT, FUNDING_REQUEST, GRANT, and UNCLASSIFIED types. Each expense requires at least one line item with description and amount.
The payee is the account that will receive the payment. The account is the collective the expense is submitted to. Requires authentication.
For bookkeeping expenses (e.g. when collective has negative balance), submit as INVOICE type.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-read-only behavior. Description adds that authentication is required and clarifies the roles of payee and account. Beyond annotations, it provides moderate additional context but lacks details on creation results or side effects.
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?
Six sentences efficiently cover purpose, types, requirements, authentication, and a use case. No redundant information; front-loaded with the core action. Slightly longer than necessary but well-organized.
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?
Given the complexity of many parameters, the description covers essentials: expense types, line items, authentication, and a special case. An output schema exists, so return value explanation is not needed. Lacks details on payout or currency, but these are in the schema.
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?
The description summarizes required line items and supported expense types, but the input schema already has descriptive property names and descriptions. The bookkeeping guidance adds marginal value beyond the schema, so baseline 3 is appropriate.
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?
Description clearly states 'Submit a new expense to an OpenCollective collective' with specific verb and resource, and lists supported expense types. This effectively distinguishes from sibling tools like oc_edit_expense and oc_delete_expense, which have different verbs.
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?
Provides usage constraints such as requiring authentication, needing at least one line item, and specifying when to use INVOICE for bookkeeping expenses. However, it does not explicitly compare this tool to alternatives like oc_edit_expense or oc_process_expense.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an expense. Requires authentication and appropriate permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds authentication requirements but does not detail effects beyond deletion, meeting the lowered bar but not exceeding it.
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?
The description is a single, concise sentence that gets straight to the point, with no extraneous words.
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 simple delete operation with existing annotations and output schema, the description is serviceable but lacks detail on side effects or post-deletion state, leaving some gaps.
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 0% because the description does not mention parameters. It adds no meaning beyond the schema's own descriptions ('Expense ID', 'Expense legacy ID'), failing to compensate for the low coverage.
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 clearly states the action ('Delete an expense') and the resource, distinguishing it from siblings like oc_create_expense and oc_edit_expense.
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 mentions authentication and permissions as prerequisites, but does not provide guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an OpenCollective account/collective profile.
Requires authentication. Use oc_get_account first to obtain the account ID. Only provided fields will be updated.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive and idempotent. Description adds authentication requirement and partial update info, but no mention of side effects or rate limits. Adequate but not exceptional.
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 concise sentences, front-loaded with purpose. Every sentence adds necessary information without fluff.
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?
Given annotations, output schema, and the tool's straightforward nature (non-destructive edit), the description covers prerequisites and behavior adequately. No major gaps.
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 descriptions are detailed (though context says 0% coverage, likely a mismatch). The description adds value by stating 'Only provided fields will be updated,' clarifying partial update semantics beyond 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?
Clearly states 'Edit an OpenCollective account/collective profile' with specific verb and resource. Distinguishes from sibling tools like oc_create_expense, oc_delete_expense, etc.
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 mentions required authentication, prerequisite tool (oc_get_account), and partial update behavior ('Only provided fields will be updated'). No explicit when-not-to-use or alternatives, 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.
Edit an account setting like monthly spending limits.
Requires authentication with account scope. Common keys:
'expensesMonthlyLimit': Monthly expense limit in EUR
'VIRTUAL_CARDS_MAX_MONTHLY_AMOUNT': Max monthly virtual card spending
'VIRTUAL_CARDS_MAX_DAILY_AMOUNT': Max daily virtual card spending
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool is non-read-only, non-destructive, and idempotent. The description adds the authentication requirement and examples of common keys, which provide some behavioral context beyond annotations. However, it does not describe any side effects, error states, or the immediacy of changes, leaving some gaps.
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?
The description is very concise: two sentences and a bullet list. The first sentence states the purpose, the second gives authentication context, and the list provides key examples. Every sentence earns its place without redundancy. Well-structured and front-loaded.
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?
Given the tool's simplicity, existence of an output schema, and annotations covering safety, the description is mostly complete. It includes common key examples and authentication. However, it misses hints about error handling for invalid keys or value types, and could mention that changes are applied immediately. Still, it provides sufficient context for an agent to use the 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?
The schema already provides descriptions for all three required parameters (slug, key, value). The description adds value by listing and explaining common keys with units (e.g., EUR for expensesMonthlyLimit). This augments schema descriptions, but does not cover all possible keys or provide syntax for value formats. Schema description coverage is effectively high in the schema itself, so the description adds moderate semantic value.
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 clearly states it edits an account setting like monthly spending limits and lists common keys. It distinguishes the tool by name and examples, but does not explicitly differentiate from oc_edit_account, which edits account-level properties. The purpose is clear and specific.
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 description notes that authentication with account scope is required, which is a usage guideline. However, it does not provide when-to-use or when-not-to-use guidance relative to sibling tools such as oc_edit_account or oc_set_budget. The context is implicit but not sufficiently explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit an existing expense. Only provided fields will be updated.
Requires authentication and appropriate permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate idempotentHint=true and destructiveHint=false. The description adds partial update behavior but does not disclose failure modes (e.g., expense not found) or side effects. It also requires authentication, which is noted.
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?
The description is two sentences, front-loaded with the main action, and contains no unnecessary information. It is concise and easy to parse.
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?
Given the presence of an output schema and annotations, the description is adequate for basic use but lacks information on error handling, such as what happens if the expense ID does not exist. It does not leverage the output schema to explain response details.
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 0% per context, meaning the tool description does not cover individual parameters. The description only states 'Only provided fields will be updated', which is a general behavior but does not add per-parameter meaning. The schema itself has parameter descriptions, but the tool description fails to compensate for the low coverage.
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 clearly states 'Edit an existing expense' with the verb 'edit' and resource 'expense', and specifies partial update behavior with 'Only provided fields will be updated'. This distinguishes it from sibling tools like oc_create_expense and oc_delete_expense.
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 description mentions authentication and permissions, but does not provide explicit guidance on when to use this tool vs alternatives, nor when not to use it. No sibling tools are referenced for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a raw GraphQL query or mutation against the OpenCollective API v2.
Use this as an escape hatch for operations not covered by other tools. The API endpoint is https://api.opencollective.com/graphql/v2. Authentication is applied automatically if OPENCOLLECTIVE_TOKEN is set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond annotations by stating that authentication is applied automatically if the token is set. It does not contradict annotations (readOnlyHint=false, destructiveHint=false). However, it could mention potential side effects of mutations.
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?
The description is three sentences long, front-loaded with the main purpose, and contains no redundant information. Every sentence adds value.
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?
Given the tool's complexity (2 params, output schema exists), the description covers the endpoint, authentication, and usage rationale. It is adequate but could note that mutations are permitted (despite destructiveHint=false, the description implies it).
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?
With 0% schema description coverage, the description compensates slightly by specifying the API version (v2) but does not detail the format or constraints of the query or variables beyond the schema's minimal descriptions.
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 clearly states 'Execute a raw GraphQL query or mutation against the OpenCollective API v2', providing a specific verb and resource. It distinguishes the tool from siblings, as no other sibling offers raw GraphQL execution.
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 description explicitly says 'Use this as an escape hatch for operations not covered by other tools', providing clear when-to-use and when-not-to-use guidance. It also mentions the endpoint and automatic authentication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about an OpenCollective account/collective by slug.
Returns account profile, stats (balance, budget, total received/spent), social links, and metadata. Works without authentication for public data.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive. Description adds valuable context by specifying the returned data includes 'account profile, stats, social links, and metadata' and states authentication requirements ('works without authentication for public data'), which complements the annotations.
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?
The description is two sentences long, front-loads the main action, and every sentence adds value. No filler or redundant information.
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 simple get-by-slug tool with an output schema, the description covers the main inputs and outputs. It could mention error handling or what happens if the slug is invalid, but the presence of an output schema likely handles that. Overall, it is sufficient.
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?
The description mentions 'by slug' but does not elaborate on the slug parameter beyond what the input schema provides. Context signals indicate 0% schema description coverage, meaning the description should compensate, but it adds no additional meaning to the parameters.
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?
Description clearly states the tool retrieves detailed information about an OpenCollective account by slug. It specifies the exact resource (account/collective) and action (get), distinguishing it from sibling tools like oc_search_accounts which searches, or oc_get_expense which fetches expenses.
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?
Description implies usage by mentioning 'by slug' and 'works without authentication for public data', but does not explicitly state when to use this tool over alternatives like oc_search_accounts for unknown accounts or oc_get_logged_in_account for the user's own account. No 'when not to use' guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific expense by ID or legacy ID.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds minimal behavioral context beyond stating it is a retrieval operation. It is consistent with annotations, providing no contradiction.
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?
The description is a single, well-structured sentence that immediately conveys the purpose. It is concise and front-loaded, with no redundant information.
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?
Given the simplicity of the tool, the presence of an output schema reduces the need to describe return values. The description is largely complete, though it does not clarify the requirement to provide at least one of id or legacy_id (both are optional in schema but implied by the description). This is a minor gap.
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 0% per context, though the schema itself includes basic descriptions for id and legacy_id. The description adds little value beyond restating 'by ID or legacy ID'. It does not explain when to use each parameter, constraints, or the effect of providing both, leaving the agent to infer from 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 clearly states the action ('Get'), the resource ('detailed information about a specific expense'), and the identification methods ('by ID or legacy ID'). It effectively distinguishes the tool from sibling tools such as oc_list_expenses or oc_create_expense, which have different verbs or resources.
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 description implies usage when the agent knows an expense ID or legacy ID and needs detailed information, but it does not explicitly say when to use this tool versus alternatives like oc_get_account or oc_list_expenses. No guidance on when not to use it is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get information about the currently authenticated account.
Requires OPENCOLLECTIVE_TOKEN to be set.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety and side effects. The description adds the requirement of 'OPENCOLLECTIVE_TOKEN', which is a valuable operational constraint beyond annotations.
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?
The description is concise: one sentence for purpose and one for a prerequisite. Every sentence adds value, and there is no extraneous information.
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 simple read-only tool with an output schema available, the description is largely sufficient. It might be improved by hinting at the scope of information returned, but the output schema can compensate. The low parameter count and clear annotations reduce the need for extensive description.
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?
The input schema has one parameter 'ctx' with no description and 0% schema description coverage. The tool description does not explain the parameter's purpose or impact, leaving the agent without guidance on whether or how to use it.
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 clearly states 'Get information about the currently authenticated account,' using a specific verb ('get') and resource ('currently authenticated account'). This clearly distinguishes it from sibling tools like 'oc_get_account' which likely requires an account identifier.
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 description explicitly states that 'OPENCOLLECTIVE_TOKEN must be set,' providing a prerequisite for usage. While it does not directly compare to alternatives, the purpose implies it should be used when the agent needs the authenticated user's own account info, not a specific account by ID.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List members and backers of an OpenCollective account.
Returns member roles (ADMIN, MEMBER, BACKER, etc.), donation totals, and linked account info.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint as false. The description adds value by specifying the returned data (roles, donations, linked account info) beyond annotations. No contradictions.
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 concise sentences, front-loaded with the main purpose. Every sentence adds value; no unnecessary words.
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?
The description covers the input (account slug) and output (roles, donations, linked info). Annotations provide safety guarantees. Minor gap: pagination (limit/offset) is not mentioned, but it's a listing tool with common parameters.
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 0% per context signal, meaning no parameter descriptions in the schema itself. The description does not explain the parameters (slug, limit, offset) beyond the main purpose, so it fails to compensate for the missing schema descriptions.
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 clearly states 'List members and backers of an OpenCollective account' with a specific verb and resource, and lists what is returned (roles, donations, linked info). It is well-distinguished from sibling tools which are mostly about invoices and expenses.
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 description implies when to use (when you need member/backer info) but does not explicitly state when not to use or provide comparisons to alternatives. However, no sibling tool serves the same purpose, so 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.
List expenses for an OpenCollective account with filtering.
Supports filtering by status, type, tags, date range, and search term. Use account_slug to filter by collective, from_account_slug to filter by payee.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds little behavioral context beyond stating it lists expenses. The description does not contradict annotations, but it also does not disclose additional traits like pagination behavior or data freshness.
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?
The description is only three sentences, front-loaded with the primary action, and every sentence adds value. No redundant or unnecessary information.
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?
Given that an output schema exists (not shown), the description does not need to detail return values. It covers key filtering options and parameter guidance. However, it could mention pagination (limit/offset) or default behavior for completeness.
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?
The input schema provides descriptions for all parameters, covering their purpose (e.g., 'Filter by status(es): DRAFT, PENDING...'). The description adds minor clarification about account_slug and from_account_slug but does not significantly enhance understanding 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 clearly states 'List expenses for an OpenCollective account with filtering', which specifies the verb (list), resource (expenses), and scope (with filtering). It distinguishes itself from sibling tools like oc_get_expense (single expense) and oc_create_expense by focusing on listing.
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 description provides explicit guidance on using key parameters: 'Use account_slug to filter by collective, from_account_slug to filter by payee.' However, it does not explicitly state when to use this tool vs. alternatives (e.g., oc_get_expense for a single expense), though this is implied by the tool name and sibling set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List transactions for an OpenCollective account (the ledger).
Shows credits and debits with amounts, descriptions, linked expenses/orders. Supports filtering by type (CREDIT/DEBIT), date range, kind, and search term.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it 'shows credits and debits' but does not elaborate on rate limits, permissions, or response structure beyond what annotations imply.
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?
The description is concise, front-loaded with the main purpose, and uses two readable sentences. Every sentence is informative without padding.
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 an output schema present and annotations covering safety, the description covers what the tool returns and filtering capabilities. However, it omits mention of pagination (limit/offset) which is in the schema but not described.
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 high (most parameters have descriptions in the schema). The tool description redundantly lists filtering types (type, date range, kind, search term) but adds no new semantic information 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 clearly states the tool lists transactions for an OpenCollective account and mentions specific fields (amounts, descriptions, linked expenses/orders). It distinguishes from sibling tools that focus on invoices, expenses, or accounts.
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 description implies usage for viewing the full ledger with filters but does not explicitly state when to use this tool over alternatives like oc_list_expenses or oc_get_expense. No explicit when-not-to-use or alternative names provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Process an expense: approve, reject, pay, hold, release, etc.
Available actions: APPROVE, UNAPPROVE, REQUEST_RE_APPROVAL, REJECT, MARK_AS_UNPAID, SCHEDULE_FOR_PAYMENT, UNSCHEDULE_PAYMENT, PAY, MARK_AS_SPAM, MARK_AS_INCOMPLETE, HOLD, RELEASE.
Requires authentication and admin/host permissions.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false, destructiveHint=false, and idempotentHint=false. The description adds important behavioral context by stating the permission requirement ('admin/host permissions'). It does not contradict annotations and provides additional operational clarity beyond what annotations offer.
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?
The description is two sentences plus an itemized list of actions. It is front-loaded with the core purpose, uses minimal words, and every element (actions list, permission note) earns its place. No wasted text.
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?
Given that an output schema exists and the tool's core behavior is well-described (actions, permissions), the description is largely complete. It could mention that the tool modifies expense state, but that is implicit from 'process' and the listed actions. The context signals indicate low parameter count and no complex nesting, so the description adequately covers the necessary information.
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?
The input schema already includes descriptions for all parameters (id, action, message, legacy_id), so the description does not need to add much. The description simply repeats the action values, which is already in the schema. Baseline 3 is appropriate since schema coverage is high and the description adds minimal extra meaning.
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 uses a specific verb 'Process an expense' and lists concrete actions (approve, reject, pay, hold, release, etc.). It clearly distinguishes this tool from siblings like oc_create_expense, oc_get_expense, and oc_delete_expense by focusing on state-changing actions on an existing expense.
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 description states 'Requires authentication and admin/host permissions', which provides necessary context for when this tool can be used. It implies usage for performing actions on an expense rather than creating or reading, but does not explicitly exclude alternative scenarios or mention alternatives. Still, it is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for OpenCollective accounts/collectives.
Supports filtering by search term and account type (COLLECTIVE, ORGANIZATION, INDIVIDUAL, FUND, PROJECT, EVENT).
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the tool's behavior is safe. The description adds filtering capabilities but does not disclose pagination behavior or result set limitations beyond 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?
The description is concise with two sentences, no redundant information, and quickly conveys the essential purpose and key filtering options.
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?
The description covers the main purpose and filtering but lacks mention of pagination or result structure. Given the presence of an output schema, this is adequate but not fully complete for all contexts.
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?
The schema already describes each parameter (max results, offset, search query, account type with enum list). The description merely restates the filtering support, adding no new semantic value 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 clearly states the action ('Search for OpenCollective accounts/collectives') and specifies filtering by search term and account type, distinguishing it from tools like oc_get_account (single) or oc_list_expenses.
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 description provides no guidance on when to use this tool versus alternatives like oc_get_account or oc_list_expenses. It only lists features without contextual advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the yearly budget goal for a collective.
Example: Set 800 EUR yearly budget for goingdark collective. Requires token with 'account' scope.
| Name | Required | Description | Default |
|---|---|---|---|
| ctx | No | ||
| params | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('Set'), consistent with annotations (readOnlyHint=false). It adds behavioral context by specifying the required auth scope. No contradiction with annotations.
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?
The description is extremely concise: two sentences plus an example, with no wasted words. It front-loads the core action and follows with a clear example and scope requirement.
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?
Given the output schema exists, the description reasonably focuses on input and preconditions. It mentions required scope and provides an example. Minor gap: does not explain behavior on duplicate call, but idempotentHint covers 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?
The input schema already provides clear descriptions for each parameter (slug, title, amount). The tool description reinforces this with an example (e.g., '800 EUR yearly budget for goingdark'), adding practical context beyond schema details.
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 clearly states the tool's action ('Set the yearly budget goal for a collective') and provides an explicit example. It distinguishes itself from sibling tools like oc_edit_account_setting by specifying the unique purpose of setting a yearly budget.
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 description mentions that a token with 'account' scope is required, providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools for similar operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tools are clearly separated by prefix (cloudflare_, hetzner_, oc_) and each tool has a distinct purpose. There is no ambiguity between tools from different services, and within groups, operations are well-differentiated (e.g., list vs. get, create vs. edit).
All tools follow a consistent naming pattern: provider/domain prefix + verb_noun in snake_case (e.g., cloudflare_list_invoices, oc_create_expense). No mixing of conventions or irregular names.
With 24 tools across three services, the count is slightly high but still reasonable for a multi-service integration server. Each service has a focused set of operations, and the number does not feel excessive.
The tool set covers core CRUD operations for Cloudflare invoices, Hetzner invoices, and OpenCollective expenses/accounts, plus additional utilities like currency conversion, PDF parsing, and a GraphQL escape hatch. The surface is comprehensive for the stated bookkeeping and expense management domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Log, query, and edit expenses, budgets, and accounts in Manilo (formerly Ledgy) from any MCP-compatible AI assistant.
Log, query, and edit expenses, budgets, and accounts in Ledgy from any MCP-compatible AI assistant.
Personal finance ledger for AI agents — query spending, track bills, forecast cash flow.
Personal finance, bank account, and shared memory connector for Claude, ChatGPT, Gemini Spark & more
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/theepicsaxguy/opencollective-hetzner-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
